Как передать больше данных, а затем имя пользователя/пароль для метода службы в службе WCF 4.0 RESTful, используя базовую аутентификацию

Требования:

WCF 4.0 Хост IIS Обычная проверка подлинности с помощью настраиваемого источника RESTful

Существует множество примеров и способов реализации базовой аутентификации, используя UserNamePasswordValidator, crough ServiceAuthorizationManager и IDispatchMessageInspector и т.д.

Проблема, с которой я столкнулась, заключается в том, что валидация фактически будет получать гораздо больше информации из бэкэнда аутентификации, чем да/нет. И я хочу каким-либо образом передать эту информацию вызываемым сервисным методам (т.е. Будет полномасштабный пользовательский объект со многими свойствами для управления поведением службы). Я хочу избежать второго вызова в хранилище пользователей для извлечения данных на основе имени пользователя, доступ к которому я могу получить из контекста безопасности.

До сих пор самое близкое, что я нашел, это это решение, в котором используется WCF REST Starter Kit RequestInterceptor, в котором я могу ввести подкласс ServiceSecurityContext для переноса моих данных и отменить ServiceSecurityContext.Current в методе службы.

Проблема с вышеизложенным заключается в том, что он написан для WCF 3.5 и что я бы хотел избежать использования Starter Kit.

Вопрос: любая идея, что было бы самым подходящим местом для присоединения к цепочке, поэтому я могу передать данные из логики проверки в службу. Или, говоря иначе, где я мог бы заменить контекст безопасности своим пользовательским, чтобы продолжить загрузку? Или любой другой механизм-носитель?

То, что мне нужно, - это поведение:

Клиент (может быть браузером) пытается использовать службу: GET https://myservcer/service/data Сервер отвечает "Требуется базовая аутентификация", Клиент отправляет основной заголовок аутентификации и снова отправляет запрос Сервер, основанный на пользователе/​​проходе в заголовке, вытаскивает объект пользователя из базы данных. Если пользователь не найден, повторите проверку подлинности Если пользователь найден, объект User каким-то образом передан методом службы Все это должно произойти без второго обращения к базе данных

До сих пор я понимаю, что UserNamePasswordValidator не будет делать - нет способа передать объект User, если я его туда заберу.

Я могу создать пользовательский IAuthorizationPolicy или SecurityToken (какой), и поместить объект User в. Но... где это должно произойти. Могу ли я пойти с UserNameSecurityTokenAuthenticator для этого? Будет ли возвращен правильный код ошибки HTTP для запроса учетных данных? Как/где я изменяю web.config для использования моих пользовательских материалов? Пока я вижу, как установить только пользовательский UserNamePasswordAuthenticator.

РЕДАКТИРОВАТЬ: pls check мой собственный ответ для моего подхода. Тем не менее, вопрос был хорошим, и полученные ответы были ценными.

Ответ 1

Мы реализовали собственный HTTP-модуль проверки подлинности. Модуль подключается к событию HttpApplication и проверяет подлинность на бэкэнд. Бэкэнд может возвращать все, что захочет (и в нашем случае он возвращает больше, чем да/нет. Возвращаемый объект реализует интерфейс System.Security.Principal.IIdentity. После успешной аутентификации мы присоединяем идентификатор (объект, возвращаемый auth) для принципала, который переносится в HttpContext.User.

Вниз по конвейеру вы можете получить доступ к текущему контексту Пользователь в любой момент и получить всю свою идентификационную информацию.

Единственный существенный недостаток этого подхода заключается в том, что он требует совместимости с ASP.net, но если вы уже используете свои службы Rest, то это не должно быть проблемой.

Ответ 2

Вы можете создать реализацию IAuthorizationPolicy и заменить первичный идентификатор тем, который вы получите во время аутентификации. Посмотрите на эти ссылки, которые показывают, как дважды ударить базу данных:

WCF Custom Validator: как инициализировать объект "Пользователь" из пользовательского валидатора

Когда и где устанавливать пользовательскую идентификацию IIdentity при реализации пользовательской аутентификации

Ответ 3

В итоге я не использовал WCF. Nancy было намного проще создавать и тестировать RESTFull API, а с последние изменения (это будет в 0,8 версии), о чем я просил, очень легко.