Разработать ошибку аутентифицируемого самоцвета Saml - AuthnRequest с AuthnContexts не поддерживается - PullRequest
Новая
       67

Разработать ошибку аутентифицируемого самоцвета Saml - AuthnRequest с AuthnContexts не поддерживается

0 голосов
/ 30 октября 2018

Я использую devise_saml_authenticatable gem, чтобы приложение Ruby on Rails выступало в качестве Service Provider (SP) , позволяя пользователям проходить аутентификацию с использованием единого входа SAML.

Idp - это решение Shibboleth, которое использует urn:oasis:names:tc:SAML:2.0:ac:classes:Password в качестве контекста authn.

Однако я застрял со следующей ошибкой: 

<Status>
  <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
    <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported" />
     </StatusCode>
     <StatusMessage> The AuthnRequest with AuthnContexts is not supported! 
     </StatusMessage>
</Status>

Я перепробовал всевозможные authn_context возможные комбинации, но, похоже, ничего не работает.

Было бы очень полезно, если бы вы могли предоставить какую-либо информацию для устранения ошибки.

Спасибо!

1 Ответ

0 голосов
/ 01 ноября 2018

Это код респондента из IdP, который в настоящее время настроен на , а не , поддерживающих поставщиков услуг, указывающих параметр AuthnContext в SAML AuthnRequest.

У вас есть settings.authn_context = "", указанный в файле config/initializers/devise.rb? Или вы указываете urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Сказать, что Shibboleth использует этот AuthnContext, является грубым преувеличением. Shibboleth поддерживает многие контекстные классы, включая пользовательские классы для таких вещей, как многофакторная аутентификация. urn:oasis:names:tc:SAML:2.0:ac:classes:Password только один из многих, которые поддерживаются Shibboleth. Какие потоки Authn разрешены администратором IdP, это другая история. Возможно, это единственный поток, который они настроили и, следовательно, поток по умолчанию.

Я бы попытался отправить AuthnRequest с пустым AuthnContext, потому что похоже, что этот конкретный IdP был настроен на отключение возможности SP указать это.

В Shib IdP 3+ это можно сделать, указав p:disallowedFeatures-ref="SAML2.SSO.FEATURE_AUTHNCONTEXT" либо для проверяющей стороны по умолчанию, либо для конкретного RelyingPartyOverride для вашего SP. Вы можете спросить администратора IdP и спросить, указывают ли они это свойство в компоненте SAML2.SSO?

...