5.5. 使用基于浏览器和 SAML 的 SSO，多个红帽 JBoss 企业应用平台实例和多个应用程序

JBoss EAP 支持通过 SAML 通过 Web 应用程序执行基于浏览器的 SSO，以及托管身份提供程序。若要托管身份提供程序，必须定义身份验证机制来配置这种情况下名为 idp-domain 的安全域。在这种情况下，idp-domain 被配置为使用 DatabaseLoginModule 作为身份验证机制。IDP 应用（如 IDP.war ）已部署到 JBoss EAP 实例，在本例中 为 EAP-IDP，并且配置为使用 idp-domain 作为其身份存储。IDP.war 使用身份存储与应用的功能相结合，以验证用户身份和角色信息，以及发行包含用户身份和角色信息的 SAML 令牌。另外三个 JBoss EAP 实例： EAP1、EAP2 和 EAP3，各自托管一个不同的应用，分别充当单独的 SP、sampleAppA.war、sampleAppB.war 和 sampleAppC。每个 JBoss EAP 实例都有一个安全域( sso-domain)，配置为使用 SAML2LoginModule 作为身份验证机制。每一应用包含支持 SSO 的功能，使用 IDP.war 作为身份提供程序，并使用 HTTP/POST 绑定进行身份验证。每个应用程序也被配置为使用so -domain 来保护路径 /secure/*，并提供自己的角色列表来处理授权。

在这种情况下，以下用户被添加到 idp-domain 安全域中 DatabaseLoginModule 使用的数据库中：

在 EAP-IDP 启动时，管理接口将启动，后跟子系统和部署的应用，包括 security 子系统（包括 idp-domain 和 IDP.war ）。IDP-domain 连接到数据库，并加载 DatabaseLoginModule 登录模块中配置的用户名、密码和角色。为了防止敏感信息以纯文本形式存储在 DatabaseLoginModule 登录模块的配置中，密码哈希被配置为模糊某些字段，例如数据库的密码。IDP.war 使用 idp-domain 进行身份验证和授权。还配置 IDP.war，使用 jboss-web.xml、web.xml、picketlink.xml 和 jboss-deployment-structure.xml，向经过身份验证的用户发布 SAML 令牌，并为用户提供简单的登录形式以进行身份验证。这允许它充当 IDP。

在 EAP1、EAP2 和 EAP3 启动时，管理接口启动，后跟子系统和部署的应用，其中包括每个实例 上的 security 子系统，以及 sampleAppA.war、sampleAppB.war 和 sampleAppC.war。SSO-domain 已配置为使用 SAML2LoginModule 登录模块，但依赖于应用来提供正确的 SAML 令牌。这意味着，任何使用 sso-domain 的应用程序都必须正确连接到 IDP 以获取 SAML 令牌。在本例中，Sample AppA、SampleAppB 和 sampleAppC 各自通过 jboss-web.xml、web.xml、picketlink.xml 和 jboss-deployment-structure.xml 配置，以使用 IDP 的登录表单从 IDP、IDP.war 获取 SAML 令牌。

每个应用程序也配置有自己的一组允许的角色：

当未经身份验证的用户尝试访问由 sso-domain（即 任何应用程序的 /secure/* ）保护的 URL 时，该用户会被重定向到 IDP.war 的登录页面。然后，用户使用表单进行身份验证，并签发包含其身份和角色信息的 SAML 令牌。用户重定向到原始 URL，其 SAML 令牌呈现给应用 SP。应用确保 SAML 令牌有效，然后根据 SAML 令牌提供的角色和应用中配置的角色授权用户。签发 SAML 令牌后，他们使用该令牌在 SSO 使用同一 IDP 保护的其他应用上进行身份验证和授权。SAML 令牌过期或无效后，用户需要从 IDP 获取新的 SAML 令牌。

在本例中，如果 Eric accesses EAP1/sampleAppA/secure/hello.html，他会被重定向到 EAP-IDP/IDP/login.html 进行登录。成功登录后，他将签发包含其用户信息和角色的 SAML 令牌，并 重定向到 EAP1/sampleAppA/secure/hello.html。他的 SAML 令牌将提供给 sampleAppA，以检查并根据他的角色授权他。因为 sampleAppA 允许所有 角色和 AB 访问 /secure/*，并且 Eric 拥有 全部 角色，因此他可以访问 EAP1/sampleAppA/secure/hello.html。

如果 Eric 尝试访问 EAP2/sampleAppB/secure/hello.html，因为尚未对该 SP 进行身份验证，他会通过身份验证请求重定向到 IDP.war。由于 Eric 已针对 IDP 进行了身份验证，因此他已被 IDP.war 重定向到 EAP2/sampleAppB/secure/hello.html，且具有该 SP 的新 SAML 令牌，无需重新身份验证。sampleAppB 检查其新的 SAML 令牌，并根据他的角色授权他。因为 sampleAppB 允许所有 角色和 AB 访问 /secure/*，并且 Eric 拥有 全部 角色，因此他可以访问 EAP2/sampleAppB/secure/hello.html。如果 Eric 试图访问 EAP3/sampleAppC/secure/hello.html，则同样适用。

如果 Eric 返回 EAP1/sampleAppA/secure/hello.html 或 EAP2/sampleAppB/secure/* 或 EAP3/sampleAppC/secure/* 下的任何 URL，则在 SAML 令牌通过全局注销无效后，他会被重定向到 EAP-IDP/IDP/login.html 以再次进行身份验证并发布新的 SAML 令牌。

如果 Amar 试图访问 EAP1/sampleAppA/secure/hello.html 或 EAP2/sampleAppB/secure/hello.html，他将被定向到与 Eric 相同的流。如果 Amar 试图访问 EAP3/sampleAppC/secure/hello.html，仍然需要他拥有或获取 SAML 令牌，但将被限制为查看 EAP3/sampleAppC/secure/hello.html，因为角色 AB 仅允许他访问 EAP1/sampleAppA/secure/* 和 EAP2/sampleAppB/secure/*。Brian 处于类似情况，但只能访问 EAP3/sampleAppC/secure/*。如果 Alan 试图访问服务提供商的安全区域，则仍然需要他拥有或获取 SAML 令牌，但会因为没有角色而被限制查看任何内容。每个 SP 都有一个不安全的区域，任何经授权与否的用户都可以查看，而无需获取 SAML 令牌。