Несоответствие URL-адресов Shibboleth ACS с http и https

URL-адрес моего ACS переписывается с https://foo.com/ на http://foo.com/, что вызывает исключение ниже.

Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.AssertionConsumerServiceUrlDoesNotMatchPolicyException: MSIS3200: Служба AssertionConsumerService не настроена на доверяющей стороне доверия 'foo-shibboleth-sp', которое является префиксом URL-адреса службы http = URL-адрес assertionCumer = As /foo/Shibboleth.sso/SAML2/POST "rel =" nofollow noreferrer "> http: //foo/Shibboleth.sso/SAML2/POST ', указанный в запросе.

Сообщение журнала отражает, что запрос аутентификации также был отправлен как http:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
AssertionConsumerServiceURL="http://foo/Shibboleth.sso/SAML2/POST" 
Destination="https://bar/adfs/ls/" 
ID="_12345ID" IssueInstant="2017-08-08T22:24:28Z" 
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Version="2.0"><saml:Issuerxmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">foo-shibboleth-sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>
2017-08-08 22:24:28 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: message encoded, sending redirect to client

Я включил свою конфигурацию ниже.

Метаданные SP, которые я настроил в своем IDP, имеют правильный URL-адрес с https, но где-то ниже по течению они меняются на http, и их можно увидеть в журналах Shibboleth для запроса аутентификации samlp.

Если я переключаю handlerSSL на TRUE, URL ACS в запросе аутентификации samlp показывает https. Однако, если для него установлено значение TRUE, все, что находится на пути к /Shibboleth.sso/, например / Status или / SAML2 / POST, отправляет ошибку 404.

Я также должен отметить, что на самом деле это миграция сайта, и все это было на Windows в центре обработки данных, теперь это на Linux в AWS. Может быть проблема с балансировщиком нагрузки, когда мы прерываем SSL, но не смогли отладить это.

В метаданных SP, предоставленных IDP, я указываю URL https / SAML2 / POST. Здесь есть куча конфигов, но я постарался выделить соответствующие вещи.

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_97e389f1c212...." entityID="foo-shibboleth-sp">

...

<init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://foo/Shibboleth.sso/Login"/>

....

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://foo/Shibboleth.sso/SAML2/POST" index="10"/>

Затем в shibboleth2.xml на моем SP у меня есть следующая конфигурация переопределения приложения:

        <ApplicationOverride id="lms" entityID="foo-shibboleth-sp"
                         homeURL="/path/to/sso/location">

        <Sessions lifetime="28800" timeout="3600" checkAddress="false"
            handlerURL="/Shibboleth.sso" handlerSSL="false"
            exportLocation="https://foo/Shibboleth.sso/GetAssertion" exportACL="127.0.0.1"
            idpHistory="false" idpHistoryDays="7">

            <!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). -->
            <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
                    relayState="cookie" entityID="http://bar/adfs/services/trust">
                <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" acsIndex="5"/>
            </SessionInitiator>
        </Sessions>

        <MetadataProvider type="XML" file="/etc/shibboleth/metadata-sp.xml"/>

        <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML" validate="true" path="/etc/shibboleth/attribute-map.xml"/>

    </ApplicationOverride>

Наконец, единственная другая часть, которая, как я определил, может вызывать проблемы, - это метаданные IDP:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="_1234-..." entityID="http://bar/adfs/services/trust">
...
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://bar/adfs/ls/" index="0" isDefault="true" />
....
      <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://bar/adfs/ls/" />
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://bar/adfs/ls/" />

Конфигурация apache также, хотя она кажется довольно резкой для печенья

<Location />
  ShibRequestSetting applicationId lms
</Location>
<Location /path/to/sso/location>
  ShibRequestSetting applicationId lms
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  require valid-user
</Location>

person Chad    schedule 09.08.2017    source источник


Ответы (1)


Проблема в конечном итоге была связана с разгрузкой SSL с помощью AWS Load Balancer. Поскольку мы завершали работу на ELB, нам нужно было установить https: // в директиве ServerName в конфигурации Apache, чтобы она генерировала самореференциальные URL-адреса https.

http://httpd.apache.org/docs/2.2/mod/core.html#servername

person Chad    schedule 11.08.2017
comment
Я знаю, что это старый пост, но у меня та же проблема. В моем случае у меня Shibboleth SP работает в IIS в Windows с SSL, выгруженным на балансировщик нагрузки AWS. Есть какие-нибудь советы по устранению этой проблемы в IIS? Я уже перенаправляю http на https в IIS, но AssertionConsumerServiceURL по-прежнему следует за префиксом исходного запроса перед перенаправлением. - person Ryan; 26.06.2020
comment
@ Райан, ты понял это? Прошло некоторое время, но я могу попытаться еще раз разобраться в этом и, возможно, найти для вас ответ. - person Chad; 29.06.2020
comment
Еще нет. Я думаю, мы приближаемся. Похоже, в исходных метаданных не было URL-адресов HTTPS, так что это может быть основной проблемой. Пришлось установить handlerSSL = true и cookieProps = https в элементе Sessions в shibboleth2.xml. Кроме того, в качестве idP используется AD FS, что усложняет ситуацию. Я надеюсь, что это сработает после этого последнего изменения и исправления правил утверждений в AD FS. Я ценю то, что вы предлагаете. - person Ryan; 29.06.2020