Menu Close
Settings Close

Language and Page Formatting Options

5.5.2. 它如何工作

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

表 5.6. IDP-domain 用户

username密码角色

eric

samplePass

all

amar

samplePass

AB

brian

samplePass

C

alan

samplePass

 

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

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

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

表 5.7. 应用程序/SP 角色

应用程序/SP允许的角色

sampleAppA

所有,AB

sampleAppB

所有,AB

sampleAppC

所有,C

当未经身份验证的用户尝试访问由 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.htmlEAP2/sampleAppB/secure/*EAP3/sampleAppC/secure/* 下的任何 URL,则在 SAML 令牌通过全局注销无效后,他会被重定向到 EAP-IDP/IDP/login.html 以再次进行身份验证并发布新的 SAML 令牌。

如果 Amar 试图访问 EAP1/sampleAppA/secure/hello.htmlEAP2/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 令牌。