web-dev-qa-db-ja.com

受信者のエンドポイントがSAML応答と一致しません

通常、私のSpring SAMLベースのサービスプロバイダー（SP）の実装は正常に機能します、ただし、次のエラーが返される場合があります。

[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）onTomcat 7with[〜＃〜] ssl [〜＃〜]有効。

このエラーを修正する方法はありますか？

注：サンプルソースコードはGithub：-にあります vdenotaris/spring-boot-security-saml-sample。

springspring-securitysamlsaml-2.0spring-saml
11
vdenotaris

問題がランダムに発生する理由はわかりませんが、問題を解決する少なくとも1つの方法は、現在のSAMLContextProviderLBの代わりにSAMLContextProviderImplを構成することです。

SAMLContextProviderLBは通常、リバースプロキシまたはロードバランサーで使用されるパブリックURLについてSpring SAMLパブリックに通知するために使用されますが、この場合、SpringSAMLにHTTPSを使用していると思わせるために使用できます。詳細については、 Spring SAMLマニュアル の章10.1 Advanced Configurationを参照してください。

また、entityBaseURLBeanにプロパティMetadataGeneratorを適切に設定する必要があります。そうしないと、生成されるメタデータは、httpまたはhttpsを使用してアプリケーションに最初にリクエストしたかどうかによって異なります。繰り返しますが、これはすべて 文書化 です。

24
Vladimír Schäfer

Spring SecuritySAMLでも同じ問題が発生しました。したがって、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;
  }
0
Patrick Kehrli

アプリケーションサーバーがロードバランサーの背後にあると思います！。

AWSアプリケーションロードバランサーの背後で実行されているApacheTomcatサーバーの場合、x-forwarded-protoヘッダーに基づいて、 RemoteIPValue を有効にする必要があります。 Tomcatはそれに応じてscheme（https）＆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+" />
0
Velu