Аутентификация/Шифрование Windows в WCF с NetTcpBinding

Question

Я пытаюсь понять, как проверка подлинности и шифрование Windows работает с NetTcpBinding в WCF. Мне нужно точно знать, какой алгоритм шифрования используется для шифрования данных, проходящих через провод (и некоторые документы для его подтверждения). Будет ли проверка подлинности/шифрование Windows по-прежнему работать, если клиент или хост не находится в домене?

Answer 1

NetTcpBinding с использованием учетных данных Windows требует, чтобы вызывающий и служба находились в одном домене - или, по крайней мере, на взаимно доверяющих доменах. В противном случае сервер не сможет проверить учетные данные Windows и откажется от вызова службы.

Что касается шифрования: вы можете выбрать и выбрать тот, который вам нужен! :-) TripleDES, AES - вы называете это с переменной длиной ключа.

См. Статью Fundamentals of WCF Security - речь идет обо всех аспектах безопасности и шифрования; также см. Документы MSDN по адресу Securing Services, который идет более подробно; хороший обзор можно найти here, показывающий свойства элемента безопасности транспорта basicHttp.

Answer 2

В прошлом году мне пришлось реализовать распределенную систему с использованием wcf, которая требовала, чтобы механизм был безопасным и работоспособным во всех слоях системы. Мы решили создать собственную архитектуру безопасности, создав двоичный зашифрованный токен. Зашифрованный токен содержал все разрешения, предоставленные данным пользователем.

Так, например, пользователь должен войти в систему и, если она будет успешно завершена, получит зашифрованный токен. Этот токен хранился локально на веб-клиенте. Все дальнейшие запросы пользователя будут содержать этот токен. Маркер использовался в нескольких уровнях архитектуры. Веб-сервер будет использовать его, чтобы решить, какие визуальные элементы включить или отключить. Поскольку сервисный уровень был открыт в Интернете, каждая открытая дверь проверяет токен на аутентификацию и проверяет, имеет ли этот токен надлежащее разрешение для выполнения данной задачи. Бизнес-уровень может снова проверяться на более конкретное право, включенное в токен.

Преимущества:

• Это не имеет значения, если бы мы использовали NetTcpBinding или любой другой тип связывания (и мы не использовать более чем один тип связывания).
• Мы сохранили много обходов в базу данных
• Мы могли бы использовать тот же маркер на различных платформах

Я знаю, что это, вероятно, не ответить на ваши конкретные вопросы, но это, возможно, дать вам некоторые для пищи для размышлений, пока вы все еще решаете внутриуровневую архитектуру вашей системы.