5.5.2. 它如何工作
在这种情况下,以下用户被添加到 idp-domain
安全域中 DatabaseLoginModule
使用的数据库中:
username | 密码 | 角色 |
---|---|---|
eric | samplePass | all |
amar | samplePass | AB |
brian | samplePass | C |
alan | samplePass |
在 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 令牌。
每个应用程序也配置有自己的一组允许的角色:
应用程序/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.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 令牌。