SSO应用程序的saml令牌生命周期应该是多少?是否有最佳实践?我们是否需要保持应用程序会话等于saml令牌生命周期?
fgw7neuy1#
SAML“令牌”的生存期通常非常短。包括响应和Assert的SAML消息通常具有IssueInstant,该消息声明了消息的创建时间。此外,声明通常具有包括NotBefore和NotOnOrAfter日期时间以及AudienceRestriction的Conditions。这基本上说明了受众应信任该声明的时间长度。声明的信任与会话保持活动状态的时间长度无关。与任何验证方法类似,用户在该特定的“即时”被验证。用户帐户可能在几秒钟后被禁用。服务提供商(应用程序)需要决定在提示用户再次登录之前将该会话保持活动状态的时间。这是一个基于风险的决策,基于所讨论的应用程序的安全需求。
<Conditions NotBefore="2022-08-20T02:45:48.365Z" NotOnOrAfter="2022-08-20T03:50:48.365Z"> <AudienceRestriction> <Audience>https://netsaml2-testapp.local</Audience> </AudienceRestriction> </Conditions>
上面的例子给予了你一个多小时的时间来信任Assert。这可能是一个有效的会话长度,但我也看到了5分钟,这可能不是一个合适的会话长度。这个条件更多的是关于处理SAML各方之间的时钟偏差,而不是其他任何东西。Assert表示用户已成功通过身份验证,而不是表示您应将会话保持为活动状态的时间
1条答案
按热度按时间fgw7neuy1#
SAML“令牌”的生存期通常非常短。
包括响应和Assert的SAML消息通常具有IssueInstant,该消息声明了消息的创建时间。
此外,声明通常具有包括NotBefore和NotOnOrAfter日期时间以及AudienceRestriction的Conditions。这基本上说明了受众应信任该声明的时间长度。声明的信任与会话保持活动状态的时间长度无关。与任何验证方法类似,用户在该特定的“即时”被验证。用户帐户可能在几秒钟后被禁用。
服务提供商(应用程序)需要决定在提示用户再次登录之前将该会话保持活动状态的时间。这是一个基于风险的决策,基于所讨论的应用程序的安全需求。
上面的例子给予了你一个多小时的时间来信任Assert。这可能是一个有效的会话长度,但我也看到了5分钟,这可能不是一个合适的会话长度。这个条件更多的是关于处理SAML各方之间的时钟偏差,而不是其他任何东西。
Assert表示用户已成功通过身份验证,而不是表示您应将会话保持为活动状态的时间