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

Question

由于动态显示的品牌和支持信息，我有一个通过多个子域访问的应用程序。我们正在转向 SSO 解决方案，这让这变得有点有趣。目前，我将 Spring Security SAML (1.0.1) 添加到 Spring Security 组合中，并在 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 和 Issuer 实际上在 AuthnRequest 中仍然有 Guy1.mistersite.com。无赖。

查看代码，您可以看到它有效地缓存在 org.springframework.security.saml.metadata.MetadataGeneratorFilter 中。当 processMetadataInitialization() 方法被命中时，它会检查是否设置了 hostsSPName、entityAlias 和 defaultBaseURL。如果他们是，那么，继续前进。那讲得通。

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

我已经做了一些概念证明并注释掉了所有空检查，因此每次命中此方法时都会重新建立每个值，因此在一个简单的情况下，这可以正常工作。我想知道因为这个 bean 本质上是一个单例，当整个不同的子域请求同时到来时会发生什么。有没有可能东西会变得混乱？该方法中的同步块是否足以防止这种考虑？

所以是的，如果这是一种安全而理智的方法来解决这个问题，比如我是否走在正确的轨道上，请告诉我！还有什么要考虑的。我什么是对的，什么是我不对的？:)

我们正在考虑就基础设施和子域而言改变方法模型，所以我想坚持使用新类扩展 Spring Security SAML 的可行性这个主题。

提前致谢！;)

以下是我对该方法的快速修复（基本上只是评论了一些东西）：

    protected void processMetadataInitialization(HttpServletRequest request) throws ServletException {

        // In case the hosted SP metadata weren't initialized, let's do it now
//Forcing this to reload the host SP name every time to deal with various subdomains where a user could come to for the same app (think branding for partner companies)
//        if (manager.getHostedSPName() == null) {

            synchronized (MetadataManager.class) {

//                if (manager.getHostedSPName() == null) {

                    try {

                        log.info("No default metadata configured, generating with default values, please pre-configure metadata for production use");

                        // Defaults
                        String alias = generator.getEntityAlias();
                        String baseURL = getDefaultBaseURL(request);

                        // Use default baseURL if not set
//                        if (generator.getEntityBaseURL() == null) {
                            log.warn("Generated default entity base URL {} based on values in the first server request. Please set property entityBaseURL on MetadataGenerator bean to fixate the value.", baseURL);
                            generator.setEntityBaseURL(baseURL);
//                        } else {
                            baseURL = generator.getEntityBaseURL();
//                        }

                        // Use default entityID if not set
//                        if (generator.getEntityId() == null) {
                            generator.setEntityId(getDefaultEntityID(baseURL, alias));
//                        }

                        EntityDescriptor descriptor = generator.generateMetadata();
                        ExtendedMetadata extendedMetadata = generator.generateExtendedMetadata();

                        log.info("Created default metadata for system with entityID: " + descriptor.getEntityID());
                        MetadataMemoryProvider memoryProvider = new MetadataMemoryProvider(descriptor);
                        memoryProvider.initialize();
                        MetadataProvider metadataProvider = new ExtendedMetadataDelegate(memoryProvider, extendedMetadata);

                        manager.addMetadataProvider(metadataProvider);
                        manager.setHostedSPName(descriptor.getEntityID());
                        manager.refreshMetadata();

                    } catch (MetadataProviderException e) {
                        log.error("Error generating system metadata", e);
                        throw new ServletException("Error generating system metadata", e);
                    }

//                }

            }

//        }

    }

以及安全配置的一部分：

    <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>

Answer 1

我一直在谷歌上搜索这个问题，发现了两种可能的方法。根据规范，您可以作为 SP 对身份验证请求进行签名，以便指定 AssertionConsumerServiceURL，而不要求它作为 SP 元数据交换的一部分提前发布和配置，但我不完全理解如何使用 Spring 做到这一点安全 SAML 扩展。这是该信息的来源。

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

就像你的做法一样，最后一种方法似乎也是一种黑客行为。希望这有帮助。

你最后做了什么？