Конечная точка получателя не совпадает с ответом SAML

Обычно моя реализация поставщика услуг (SP) на основе Spring SAML работает нормально, но иногда возвращает следующую ошибку:

[2014-07-17 16:00:58.767] boot - 1078 DEBUG [http-bio-80-exec-1] --- BaseMessageDecoder:     Successfully decoded message.
[2014-07-17 16:00:58.767] boot - 1078 DEBUG [http-bio-80-exec-1] --- BaseSAMLMessageDecoder: Checking SAML message intended destination endpoint against receiver endpoint
[2014-07-17 16:00:58.768] boot - 1078 DEBUG [http-bio-80-exec-1] --- BaseSAMLMessageDecoder: Intended message destination endpoint: https://prismasp.cloud.reply.eu:443/MIUR_PRISMA-2.1-WEBUI/saml/SSO/alias/defaultAlias
[2014-07-17 16:00:58.768] boot - 1078 DEBUG [http-bio-80-exec-1] --- BaseSAMLMessageDecoder: Actual message receiver endpoint: http://prismasp.cloud.reply.eu:443/MIUR_PRISMA-2.1-WEBUI/saml/SSO/alias/defaultAlias
[2014-07-17 16:00:58.768] boot - 1078 ERROR [http-bio-80-exec-1] --- BaseSAMLMessageDecoder: SAML message intended destination endpoint 'https://prismasp.cloud.reply.eu:443/MIUR_PRISMA-2.1-WEBUI/saml/SSO/alias/defaultAlias' did not match the recipient endpoint 'http://prismasp.cloud.reply.eu:443/MIUR_PRISMA-2.1-WEBUI/saml/SSO/alias/defaultAlias'
[2014-07-17 16:00:58.782] boot - 1078 DEBUG [http-bio-80-exec-1] --- SAMLProcessingFilter: Incoming SAML message is invalid
org.opensaml.xml.security.SecurityException: SAML message intended destination endpoint did not match recipient endpoint
...

Я использую (по умолчанию для Spring Security) HTTP Strict Transport Security (HSTS) на Tomcat 7 с SSL < / strong> включен.

Есть ли способ исправить эту ошибку?

Примечание. Пример исходного кода находится на Github: vdenotaris / spring-boot-security-saml-sample.


spring spring-security saml saml-2.0 spring-saml
person vdenotaris    schedule 17.07.2014    source источник
comment
Я думаю, вы пропустили 's' в протоколе, настроенном в вашей конечной точке idp. Вы ожидаете https, но кажется, что получаете http.   -  person alain.janinm    schedule 17.07.2014
comment
Текущая конфигурация обычно работает нормально, но иногда она вызывает ошибку, как указано выше. Думаю, проблема в другом. Может быть, мне вручную настроить метаданные, может быть, я пропустил определенную настройку (я просто предполагаю).   -  person vdenotaris    schedule 17.07.2014
comment
Ссылка дает мне страницу ошибки Whitelabel. Это не метаданные. Кроме того, это связано с проводным, когда вы говорите, что обычно работает нормально, должно работать всегда или никогда! Думаю, тут какое-то отношение к протоколу. Может быть, иногда вы подключаетесь с http, а иногда с https. И ваш idp, похоже, ожидает https.   -  person alain.janinm    schedule 17.07.2014
comment
Вместо / была просто 7.   -  person vdenotaris    schedule 18.07.2014

Ответы (3)


arrow_upward
30
arrow_downward

Я не знаю, почему ваша проблема возникает случайно, но, по крайней мере, один способ исправить это - настроить SAMLContextProviderLB вместо текущего SAMLContextProviderImpl.

SAMLContextProviderLB обычно используется, чтобы сообщить Spring SAML общедоступному об общедоступном URL-адресе, используемом на обратном прокси-сервере или балансировщике нагрузки, но в этом случае вы можете использовать, чтобы заставить Spring SAML думать, что он использует HTTPS. Подробности можно найти в главе 10.1 Расширенная конфигурация документа Spring руководство по SAML.

Вы также должны убедиться, что правильно установили свойство entityBaseURL в вашем MetadataGenerator bean-компоненте, потому что в противном случае сгенерированные метаданные будут зависеть от того, сделали ли вы первый запрос к вашему приложению с помощью http или https. Опять же, все это задокументировано.

person Vladimír Schäfer    schedule 17.07.2014
comment
вы также можете использовать TLSProtocolConfigurer, см .: docs.spring.io/spring-security-saml/docs/2.0.x/reference/ - person Gregor; 06.11.2018

arrow_upward
4
arrow_downward

У меня была такая же проблема с Spring Security SAML. Поэтому мне пришлось изменить contextProvider с SAMLContextProviderImpl:

  @Bean
  public SAMLContextProviderImpl contextProvider() {
      return new SAMLContextProviderImpl();
  }

в SAMLContextProviderLB:

  @Bean
  public SAMLContextProviderLB contextProvider() {
    SAMLContextProviderLB samlContextProviderLB = new SAMLContextProviderLB();
    samlContextProviderLB.setScheme(scheme);
    samlContextProviderLB.setServerName(serverName);
    samlContextProviderLB.setContextPath(contextPath);
      return samlContextProviderLB;
  }
person Patrick Kehrli    schedule 05.12.2019

arrow_upward
0
arrow_downward

Я думаю, что ваш сервер приложений находится за балансировщиком нагрузки!

Для сервера Apache Tomcat, который работает за балансировщиком нагрузки приложений AWS, необходимо включить RemoteIPValue, чтобы на основе заголовка x-forwarded-proto Tomcat перезаписывал схему (https) & < strong> port (443) соответственно.

В server.xml

<Valve className="org.apache.catalina.valves.RemoteIpValve" protocolHeader="X-Forwarded-Proto" internalProxies="10\.\d+\.\d+\.\d+|192\.168\.\d+\.\d+|169\.254\.\d+\.\d+|127\.\d+\.\d+\.\d+|172\.(1[6-9]|2[0-9]|3[0-1])\.\d+\.\d+" />
person Velu    schedule 13.08.2019