Вопрос уже поднимался, но нормального ответа так и не нашёл...

Итак, диспозиция:
— есть WCF-сервис
— есть разнообразные клиенты, к нему обращающиеся (всё на .net)
— используемая привязка: webHttp, в перспективе перейти на netHttp, для некоторых клиентов — на tcp или pipes
— Windows-аутентификация не используется, пользователи с паролями лежат в БД
— требуется: юзер выполняет вход — вводит логин-пароль, при успешном входе все последующие запросы к сервису должны считаться от имени этого вошедшего пользователя
— WCF-сессии не используются, сервисы stateless
— работа с сервисами через ChannelFactory (не Service Reference)

Схема реализации в голову приходит такая:
— для входа юзера приложение дёргает какой-то метод сервиса, в ответ (в случае успеха) получает какой-то token/ticket/coockie
— далее этот token/ticket/coockie как-то передаётся во все запросы
— на серверной стороне этот token/ticket/coockie извлекается, проверяется, по нему определяется что за юзер

Это нормальный подход? Есть ли другие варианты?

Существуют ли какие-то готовые решения для такого?


Пока нашёл два пути реализации:

1. использовать хидеры запроса (http или soap): в них для каждого обращение к сервису клиентское приложение кладёт token/ticket/coockie, на серверной стороне используется свой ServiceAuthorizationManager.
Подход работает, но в целом напрягает что не используются стандартные механизмы — например, ServiceSecurityContext говорит что пользователь не аутентифицирован. Соответственно, авторизацию делаем руками. В общем, какое-то велосипедное решение.

2. использовать стандартные Credentials: кладём token/ticket/coockie в channelFactory.Credentials.UserName. На сервере используем свой UserNamePasswordValidator.
Этот подход ещё не применяли, но в целом кажется получше — ServiceSecurityContext уже показывает что пользователь аутентифицирован, скорее всего заработают стандартные механизмы авторизации. Но всё равно остаётся ощущение неверного использования — ведь channelFactory.Credentials.UserName подразумевает указание имени пользователя и пароля, а мы используем его для других целей.


Ещё смотрел на System.Web.ApplicationServices.AuthenticationService — но похоже это что-то сильно завязанное на http и asp.net, с другими протоколами наверно не взлетит.