Обычная проверка подлинности WCF и проверка подлинности настраиваемого токена

У меня есть служба RESTful WCF с использованием обычной проверки подлинности, настраиваемый узел службы и файл. У меня настроен пользовательский UserNamePasswordValidator, и пользовательский IPrincipal правильно проходит через операцию. Однако для совместимости с прежними версиями мне необходимо поддерживать другой режим аутентификации. Как это должно работать:

  1. Пользовательские POST-сообщения для URI входа
  2. Служба аутентифицирует пользователя, как указано выше, но возвращает токен сеанса (зашифрованные учетные данные пользователя) в качестве заголовка ответа HTTP.
  3. Все последующие запросы от пользователя содержат токен сеанса вместо обычной проверки подлинности.

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

  • Каким-то образом раскрывает свойства сообщения И
  • Выполняется перед выполнением настраиваемого UserNamePasswordValidator ..

Кто-нибудь из вас, гуру, знает о такой точке расширения или способе настройки механизма безопасности транспорта? Честно говоря, меня сбивает с толку огромное количество вариантов, а просмотр пространств имен System.ServiceModel в Reflector был разочарованием.

Спасибо!


rest c# basic-authentication wcf
person Ben    schedule 20.07.2010    source источник
comment
Я также хотел бы знать, возможно ли это. Не удалось найти слишком много об идее использования ключа сеанса для последующих запросов аутентификации.   -  person Joshua Hayes    schedule 19.08.2010

Ответы (1)


arrow_upward
2
arrow_downward

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

Вместо этого я заменил UserNamePasswordValidator на IAuthorizationPolicy. Внутри метода Evaluate политики другой класс обрабатывает проверку базовых учетных данных или сеансового ключа и возвращает настраиваемый IIdentity. Ключевым моментом здесь является то, что при успешной аутентификации новый список, содержащий настраиваемый идентификатор, добавляется к свойству «Identities» evaulationContext, и добавляется настраиваемый участник к свойству «Principal». После установки этих свойств WCF правильно передает участника в операцию.

Это оказалось удовлетворительным решением, но я все еще разочарован тем, что не нашел точку расширяемости, которую искал.

person Ben    schedule 26.08.2010