Spring security Spring Security SAML使用多个子域访问同一应用程序（同一IP）_Spring Security_Spring Saml

Spring security Spring Security SAML使用多个子域访问同一应用程序（同一IP）

spring-security

Spring security Spring Security SAML使用多个子域访问同一应用程序（同一IP）,spring-security,spring-saml,Spring Security,Spring Saml,我有一个通过多个子域访问的应用程序，因为品牌和支持信息是动态显示的。我们正在转向一个SSO解决方案，这使它变得有点有趣。目前，我将Spring Security SAML（1.0.1）添加到Spring Security mix中，并在IdP中使用WSO2 Identity Server。它运行得很好当同一地址有多个DNS条目时，我们遇到的问题是保留服务提供商端的子域。例如，假设我有下面的子域指向同一个位置，guy1.mistersite.com和guy2.mistersite.com。当首次

我有一个通过多个子域访问的应用程序，因为品牌和支持信息是动态显示的。我们正在转向一个SSO解决方案，这使它变得有点有趣。目前，我将Spring Security SAML（1.0.1）添加到Spring Security mix中，并在IdP中使用WSO2 Identity Server。它运行得很好

当同一地址有多个DNS条目时，我们遇到的问题是保留服务提供商端的子域。例如，假设我有下面的子域指向同一个位置，guy1.mistersite.com和guy2.mistersite.com。当首次通过guy1.mistersite.com启动应用程序服务器时，绝对第一次访问应用程序时，来自SP的AuthnRequest将在AssertionConsumerServiceURL和Issuer中指示它来自guy1.mistersite.com。好。现在，下一次尝试从guy2.mistersite.com进行访问时，AssertionConsumerServiceURL和颁发者在AuthnRequest中实际上仍然拥有guy1.mistersite.com。糟糕透了

通过查看代码，您可以看到它被有效地缓存在 org.springframework.security.saml.metadata.MetadataGeneratorFilter。当点击processMetadataInitialization（）方法时，is检查是否设置了hostedSPName、entityAlias和defaultBaseURL。如果他们是，那么，继续前进。这是有道理的

子类化MetadataGeneratorFilter并覆盖processMetadataInitialization（）真的是一种有效且“安全”的解决方案吗

我已经做了一点概念证明，并注释掉了所有的空检查，因此每次命中此方法时都会重新建立每个值，因此在一个简单的情况下，这很好。我想知道，既然这个bean本质上是一个单实例，那么当一个不同的子域请求同时出现时会发生什么。有没有可能把东西弄得乱七八糟？该方法中的同步块是否足以防止这种情况

所以是的，如果这是一个安全和理智的方法来处理这个问题，比如我是否在正确的轨道上，让我知道！还有什么要考虑的吗。什么是我对的，什么是我不对的？：）

我们正在考虑改变基础设施和子域的方法模型，因此我想继续讨论是否可以使用新类扩展Spring Security SAML

提前感谢！；）

下面是我对该方法的快速修复（只是基本上注释了一些内容）：

和部分安全配置：

    <bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
        <constructor-arg>
            <bean class="org.springframework.security.saml.metadata.MetadataGenerator">
                <property name="extendedMetadata">
                    <bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
                        <property name="idpDiscoveryEnabled" value="false"/>
                        <property name="signMetadata" value="false"/>
                    </bean>
                </property>
                <!-- We leave these out and values are defaulted to entityId = url that user came in on
                and entityId = <entityBaseUrl>/saml/metadata.  We have to configure a SP in WSO2 for every
                subdomain we have -->
                    <property name="wantAssertionSigned" value="false" />
            </bean>
        </constructor-arg>
    </bean>

我一直在谷歌上搜索，它发现了两种可能的方法。根据规范，您可以作为SP对身份验证请求进行签名，以便指定AssertionConsumerServiceURL，而无需将其作为SP元数据交换的一部分进行发布和配置，但我不完全理解如何使用Spring Security SAML extendtion来实现这一点。以下是该信息的详细信息

我一直在讨论的另一个方法是重写MetadataGenerator中的buildSPSSODescriptor，然后查找该环境的可能子域（我们的数据库中有可用子域），然后我将循环该列表并为每个子域创建一个条目

就像你做这件事的方式一样，最后一种方式似乎也是一种恶作剧。希望这能有所帮助

你最后做了什么

你能让它工作吗？

    <bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
        <constructor-arg>
            <bean class="org.springframework.security.saml.metadata.MetadataGenerator">
                <property name="extendedMetadata">
                    <bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
                        <property name="idpDiscoveryEnabled" value="false"/>
                        <property name="signMetadata" value="false"/>
                    </bean>
                </property>
                <!-- We leave these out and values are defaulted to entityId = url that user came in on
                and entityId = <entityBaseUrl>/saml/metadata.  We have to configure a SP in WSO2 for every
                subdomain we have -->
                    <property name="wantAssertionSigned" value="false" />
            </bean>
        </constructor-arg>
    </bean>