Здравствуйте, Poul_Ko, Вы писали:
Давайте так, обычно с точки зрения передачи Credentials выбирают один из 2-х подходов:
Передавать credentials в каждом запросе. Этот режим является стандартным для почти все встроенных bindings
Передавать credentials один раз, получать некий security token и затем в каждом запросе передавать этот токен (пока не истечет время жизни токена)
Честно говоря, если нет каких-то серьезных оснований для иного я бы предложил вам остановиться на первом варианте. Т.е. работать по следующей схеме:
Во всех протоколах перейти на <security mode="Message"> и <message clientCredentialType="UserName"> (увы, не поддерживается в Named Pipes)
Аутентификацию на всех сервисах проводить используя тот самый UserNamePasswordValidator, только проверять он будет не токен, а непосредственно сами пользователя и пароль
Вторая схема (с выдачей security token) полезна в случае, если вы выделяете один authentication server, который обслуживает множество прикладных сервисов. Это особенно полезно когда:
Сервисы разрабатываются разными организациями (и не у каждой есть лоступ с credentials пользователей)
Схемы разрабатываются разными группами — тогда они становятся менее зависимыми от инфраструктуры (менее связанные).
Для этой схемы есть встроенная поддержка на базе wsFederationHttpBinding и ws2007FederationHttpBinding.
Я описывал некоторые моменты такой работы в постах на RSDN, возможно, вам будет интересно (правда там использовался готовый Identity server, но во-первых, он очень расширяемый и вы можете адаптировать тот код под себя, а во-вторых, создавть полностью свой WS-Federation или WS-Trust сервер не так и сложно).
Но! Этот вариант только для HTTP транспорта.
По поводу своих вариантов передачи и вашхи вопросов
P_K>1. использовать хидеры запроса (http или soap): в них для каждого обращение к сервису клиентское приложение кладёт token/ticket/coockie, на серверной стороне используется свой ServiceAuthorizationManager.
Вообще-то довольно распространенный вариант.
Почему у вас не создается нормальный ServiceSecurityContext — не могу сказать. На сколько я помню, можно указать что вы будете создавать полностью свой IPrincipal и формировать его как вым заблагороссудится. А уже ServiceSecurityContext должен подхватывать его.
P_K>2. использовать стандартные Credentials: кладём token/ticket/coockie в channelFactory.Credentials.UserName. На сервере используем свой UserNamePasswordValidator.
Не стоит так делать. В вашем коде потом сам черт сломит ногу.
Уж лучше, как я писал выше передавайте через этот механизм сами credentials.
