Spring SAML: конечная точка назначения сообщения SAML не соответствует конечной точке получателя - PullRequest
Новая
       79

Spring SAML: конечная точка назначения сообщения SAML не соответствует конечной точке получателя

1 голос
/ 06 марта 2019

Я получаю исключение 'Caused by: org.opensaml.xml.security.SecurityException: SAML message intended destination endpoint did not match recipient endpoint' во время единого входа между SP приложения и IdP клиента.

Журнал сервера показывает разницу в схемах, см. Ниже: 

Checking SAML message intended destination endpoint against receiver endpoint
2019-03-05 15:02:44.599 DEBUG [204 default task-41][BaseSAMLMessageDecoder] Intended message destination endpoint: https://my.app.com/app-gateway/saml/SSO
2019-03-05 15:02:44.599 DEBUG [204 default task-41][BaseSAMLMessageDecoder] Actual message receiver endpoint: http://my.app.com/app-gateway/saml/SSO
2019-03-05 15:02:44.600 ERROR [204 default task-41][BaseSAMLMessageDecoder] SAML message intended destination endpoint 'https://my.app.com/app-gateway/saml/SSO' did not match the recipient endpoint 'http://my.app.com/app-gateway/saml/SSO'

Мое приложение работает на STG в 2 экземплярах с LB впереди, поэтому я использую SAMLContextProviderLB провайдер контекста вместо SAMLContextProviderImpl: 

<bean id="contextProvider" class="org.springframework.security.saml.context.SAMLContextProviderLB">
        <property name="scheme" value="https"/>
        <property name="serverName" value="my.app.com"/>
        <property name="serverPort" value="443"/>
        <property name="includeServerPortInRequestURL" value="false"/>
        <property name="contextPath" value="/app-gateway"/>
    </bean>

<bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
        <constructor-arg>
            <bean class="org.springframework.security.saml.metadata.MetadataGenerator">
                <property name="entityBaseURL" value="https://my.app.com/app-gateway1"/>
                <property name="entityId" value="${cas.sso.entityId}"/>
                <property name="includeDiscoveryExtension" value="false"/>
                <property name="extendedMetadata" ref="extendedMetadata"/>
                <property name="keyManager" ref="keyManager"/>
            </bean>
        </constructor-arg>
    </bean>

В исходном коде getActualReceiverEndpointURI URL-адрес конечной точки получателя берется из запроса httpRequest obj. Таким образом, я пытаюсь понять, на каком этапе был задан неправильный URL http://my.app.com/app-gateway/saml/SSO. Кто-нибудь может мне это объяснить? 

protected String getActualReceiverEndpointURI(SAMLMessageContext messageContext) throws MessageDecodingException {
        InTransport inTransport = messageContext.getInboundMessageTransport();
        if (! (inTransport instanceof HttpServletRequestAdapter)) {
            log.error("Message context InTransport instance was an unsupported type: {}", 
                    inTransport.getClass().getName());
            throw new MessageDecodingException("Message context InTransport instance was an unsupported type");
        }
        HttpServletRequest httpRequest = ((HttpServletRequestAdapter)inTransport).getWrappedRequest();

        StringBuffer urlBuilder = httpRequest.getRequestURL();

        return urlBuilder.toString();
    }

1 Ответ

3 голосов
/ 07 марта 2019

Возможно, вы захотите проверить следующую страницу: https://developer.jboss.org/thread/240113

У меня была похожая проблема, даже если X-Forwarded-Proto правильно настроен на LB, запрос все еще интерпретировался только в http. Сервер должен знать заголовок.

add proxy-address-forwarding = "true" для прослушивателя http и два фильтра-ref 

<http-listener name="default" socket-binding="http" proxy-address-forwarding="true"/>  
            <filter-ref name="server-header"/>  
            <filter-ref name="x-powered-by-header"/>

Надеюсь, это поможет,

...