Как увидеть статус перенаправления из STS / IdP - PullRequest
Новая
       70

Как увидеть статус перенаправления из STS / IdP

1 голос
/ 12 марта 2012

Я искал (даже пробовал) ответ на этот вопрос, но пока не нашел ничего полезного. Я довольно плохо знаком с ADFS, STS в целом и WIF, поэтому прошу прощения за любое очевидное невежество или ненадлежащее использование терминологии. ;)

В настоящее время я интегрирую пользовательское приложение MVC3 с внешним IdP через ADFS. Настройка ADFS to IdP все готово и работает.

Некоторые части сайта доступны для всех пользователей - в режиме аутентификации web.config было установлено значение none. Другие части защищены тем, что их контроллеры / методы действий украшены пользовательским System.Web.Mvc.AuthorizeAttribute.

Все обычные изменения в файле web.config для использования модуля WsFederationAuthenticationModule были сделаны, и он работает на 95%; Пользователь может просматривать анон доступные части сайта. Когда они пытаются попасть в защищенные части, атрибут authorize проверяет, есть ли у них какая-либо пользовательская информация из нашего IdP в IClaimsPrincipals, связанной с HttpContext.Current.User, а затем устанавливает ActionResult в 401, если нет; WsFederationAuthenticationModule запускается и перенаправляет их на страницу входа IdP. Когда они вводят свои данные, они успешно перенаправляются с некоторыми файлами cookie FedAuth, и авторизация проходит.

Проблема начинается, когда они попадают на страницу входа IdP. Этот конкретный IdP имеет ссылку, чтобы вернуть вас непосредственно на наш сайт (на ту же страницу, к которой был сделан исходный запрос), где этот ответ SAML где-то встроен (это в соответствии с их документацией)

urn: оазис: имена: tc: SAML: 2.0: статус: AuthnFailed

На данный момент они «не авторизованы», и все, что увидит пользователь (по крайней мере, в dev), - это страница 401. Вы должны прекратить сеанс или иначе избавиться от этого куки, чтобы начать снова.

Что мне нужно сделать, так это перехватить запрос перенаправления от IdP и по существу проверить этот конкретный статус SAML, потому что пользователь должен быть перенаправлен в одну из неавторизованных областей, как будто ничего не произошло. Я пробовал что-то подобное в global.asax: 

 protected void Application_Start()
    {
        // mvc stuff here....

        // add handler to intercept handling creation of security tokens by WsFederationAuthnticationModule
        FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;
    }

    void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
    {
        FederatedAuthentication
            .WSFederationAuthenticationModule
            .SessionSecurityTokenCreated += WSFederationAuthenticationModule_SecuityTokenCreated;
    }

    public void WSFederationAuthenticationModule_SecuityTokenCreated (Object sender, SessionSecurityTokenCreatedEventArgs args) 
    {          
        var token = args.SessionToken;
        // do something with the session token here e.g. check for SAML status
    }

.. но я не вижу ничего полезного на этом жетоне; ничего не указывает на конкретный статус ответа. Тот факт, что существует файл cookie FedAuth на всех , но никакая пользовательская информация из Idp не дает точного подтверждения того, что пользователь был там, но каким-то образом не прошел проверку подлинности, но в принципе я хочу иметь возможность видеть этот статус. Возможно, мне также придется иметь дело с таймаутами в IdP ...

Может быть, я делаю все это неправильно, или просто старый не понимает, но может как-то объяснить мне, как определить эти статусы ответа?

Уф. Спасибо! : D

1 Ответ

2 голосов
/ 13 марта 2012

Хорошо, я собираюсь ответить на свой вопрос.

Ответ на вопрос, могу ли я получить этот пользовательский статус из моего IdP, на данный момент - нет. (

Но это только потому, что ADFS не настроена на захват и передачу. По-видимому, вам нужно выполнить какое-то пользовательское кодирование для сбора информации из обратного канала, который открыт между ADFS и IdP .... далеко за пределы текущего объема работы.

Как обойти на данный момент:

  • Если на сайт поступил запрос, и токен SAML НЕТ, то это новый запрос пользователя, который не предпринял попытки авторизации на Idp
  • Если в токене есть токен SAML, но нет идентификатора IdP (который присутствует только при правильной аутентификации), то по какой-то причине пользователь не прошел аутентификацию
    • Если есть токен SAML с присутствующим идентификатором, то аутентификация пользователя будет правильной

Не отлично, но приемлемо. Кстати, весь кредит идет в YMC в этой SO записи для следующего кода, который позволяет вам проверять токены SAML: 

void WSFederationAuthenticationModule_SecurityTokenReceived(object sender, SecurityTokenReceivedEventArgs e)
    {
        var message = SignInResponseMessage.CreateFromFormPost(Request) as SignInResponseMessage;
        var rstr = new WSFederationSerializer()
            .CreateResponse(message,
            new WSTrustSerializationContext(
                SecurityTokenHandlerCollectionManager.CreateDefaultSecurityTokenHandlerCollectionManager()));
    }

Pce!

...