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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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