Здравствуйте, Poul_Ko, Вы писали:

P_K>Это придётся в клиенте постоянно хранить в памяти пароль, который ввёл юзер. Для случая с ASP.NET неудобно.
Ну для Desktop и мобильных клиентов это нормально.

Что касается web-решений, то в любом случае вам нужно где-то хранить или сами credentials, или токен. Я не вижу между этими двумя случаями принципиальной разницы.
Варианты хранения понятны: хранилище сессионных данных на сервере или в зашифрованном виде на клиенте (куки/скрытые поля страниц/в коде JS/...)

P_K><security mode="Message"> и <message clientCredentialType="UserName"> — не запустилось с netHttpBinding. Предлагает использовать TransportWithMessageCredential, что в свою очередь требует SSL...
Ну всё верно, пароль в Message передается в открытом виде, его надо защищать.
Поэтому либо TransportWithMessageCredential поверх SSL, либо включить шифрование сообщений (но надо будет указывать сертификат на стороне сервисов)

Кстати, поинтересуюсь — а почему вы хотите использовать netHttpBinding? По сравнению с basicHttpBinding и wsHttpBinding я вижу только одно преимущество — поддержку дуплексного режима работы (но для того же WS есть wsDualHttpBinding).

P_K>Отдельный Identity-сервер тоже не охота городить. Тем более что
МР>>Но! Этот вариант только для HTTP транспорта.
А что смущает?
Если наличие еще одной точки деплоя, то это можно решить, включив код Identity Server (причем можно оставить только часть для поддержки сервисов) в свои сервисы.

Ну и вновь поинтересуюсь — а каковы резоны отказа от HTTP в пользу TCP и уж тем более Named Pipes (его обычно рекомендуют использовать лишь для межпроцессных вызовов, а не для передачи по сети)?


P_K>Да вот как-то не разобрался как создавать полностью свой IPrincipal и подсовывать его в ServiceSecurityContext. Спасибо за наводку, надо покопать ещё в этом направлении. Если есть ссылки по теме — буду благодарен.
Возможно, я за давностью лет что и позабыл. Не исключено, что ServiceSecurityContext создается до того как отработает IAuthorizationPolicy — надо тестировать.
Попробуйте посмотреть, например, вот такую статью Custom Authorization in WCF — с точки зрения кода там делается ровно то, что я предлагал: создается свой IPrincipal (на самом деле это не обязательно, можно создавать экземпляры стандартного GenericPrincipal) и передается дальше по WCF pipeline.
Единственная разница — в статье предполагается, что до того, как сработала полититка авторизации, уже отработл код отвечающий за аутентификацию и он создал готовые Identity, которые сохранил в переменных pipeline. А я бы предложил попробовать и Identity создать самому.