2010-07-20 5 views
2

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

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

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

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

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

Спасибо!

+0

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

ответ

2

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

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

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

Смежные вопросы