Использование DotNetOpenAuth в качестве поставщика OpenID в пользовательской сборке httphandler

Question

У меня есть сборка, которая действует как пользовательский HttpHandler (реализует IHttpHandler и зарегистрирован в блоке в web.config), который я хотел бы предоставить для обеспечения функциональности поставщика openid. Рассматривая примеры DotNetOpenAuth, я смоделировал свой обработчик после OpenIdOfflineProvider - поскольку этот образец (по крайней мере, в его корнях) представляет собой простой HttpListener со всеми функциями провайдера в коде. Я нахожусь в точке, где я могу предоставить свой URL проверяющей стороне (пример веб-формы rp) и увидеть запрос IAuthenticationRequest. Если я установлю IAuthenticationRequest.IsAuthenticated = true, тогда аутентификация пройдет успешно.

Однако - на данный момент я бы хотел перенаправить пользователя на пользовательскую страницу для входа в систему (поскольку мне требуется больше, чем простое имя пользователя / пароль) перед настройкой IAuthenticationRequest.IsAuthenticated соответствующим образом. Я попытался сделать это способом «веб-форм» следующим образом:

private void DoAuthentication(IAuthenticationRequest request, HttpContext context) 
{    
    if (context.Request.IsAuthenticated)
    {
        request.IsAuthenticated = true;
    }
    else
    {                
        FormsAuthentication.RedirectToLoginPage();
    }
}

Это работает почти так же, как клиентский браузер перенаправляется, и пользователь может войти в систему, эффективно устанавливая cookie для проверки подлинности форм, но когда страница входа в систему выполняет FormsAuthentication.RedirectFromLoginPage (), он чувствует, что весь контекст потерян ( я просто вижу страницу / провайдера и IAuthenticateRequest является нулевым). В этот момент, как и следовало ожидать, с установленным файлом cookie, если я повторно отправлю свой URL проверяющей стороне, все будет работать правильно, и аутентификация пройдет успешно.

Есть ли способ поддерживать контекст, необходимый для того, чтобы это могло работать? Или другой способ эффективно потребовать от пользователя перехода на страницу формы до обработки запроса IAuthenticationRequest?

Answer 1

Да, конечно, есть способ.Вам просто нужно сохранить экземпляр IAuthenticationRequest.Вы можете сохранить его в памяти или использовать BinaryFormatter для его сериализации, чтобы повысить масштабируемость и десериализовать его, когда пользователь вошел в систему. В ASP.NET этот экземпляр хранится в словаре сеансов.

Когда вы используете FormsAuthentication.RedirectToLoginPage, это просто отправляет ответ 301 обратно клиенту с аргументом строки запроса? ReturnUrl = provider.ashx .Когда страница входа в систему вызывает FormsAuthentication.RedirectFromLoginPage, она использует этот параметр ReturnUrl, чтобы узнать, куда перенаправить пользователя дальше.

Таким образом, чтобы все это работало, обычно поток будет:

1. Обработчик провайдера видит входящий запрос аутентификации и сразу же сохраняет его в пользовательском сеансе (если вы этого не сделаетечтобы в вашем обработчике была доступна сессия, и вы не хотите добавлять ее, вы должны вручную использовать куки для отслеживания этого).
2. Затем ваш провайдер перенаправляет пользователя на страницу «принятия решения», где пользователю обычно выдается «Вы уверены, что хотите войти в систему RP ?»
3. Ваша страница принятия решения сфальсифицирована и требует входа в систему пользователя, поэтому, если пользователь не вошел в систему, вы затем позвоните RedirectToLoginPage.Обратите внимание, что, поскольку вы выполнили этот метод со страницы принятия решения, пользователь вернется к этой странице принятия решения после входа в систему.
4. Пользователь входит в систему. Страница входа вызывает RedirectFromLoginPage.
5. Страница решениятеперь видит вошедшего в систему пользователя и ищет IAuthenticationRequest из сеанса.Если пользователь доверяет RP, запрашивая регистрацию, вы можете немедленно установить IsAuthenticated = true и перенаправить пользователя обратно в RP.В противном случае страница решения отображает HTML для пользователя, чтобы представить решение пользователю.Затем вы отвечаете на это, устанавливая IsAuthenticated = true или false и перенаправляя пользователя обратно в RP.

Имеет ли смысл то, как вы могли бы сделать это хотя бы частично из пользовательского обработчика?Возможно, только пользовательская конечная точка OP будет вашим пользовательским обработчиком, а все остальное в этом потоке (3-end) будет стандартными страницами ASPX.