为什么共享会话实施SSO不好?我正在学习SSO系统。
考虑这个场景:
假设所有对业务服务的http请求都需要登录,业务服务需要通过询问CAS或SAML中的SSO服务来验证请求是否登录。如果有10个业务服务,并且每个服务的请求都是1k req/s
,那么SSO服务的请求是10k req/s
。 SSO服务可以保留的图像很难。
因此,业务服务中可能存在用于验证登录令牌的缓存机制。但是当用户注销时,SSO服务需要删除验证信息,业务服务也需要删除缓存验证信息。我觉得这太复杂了。 SSO服务需要告诉业务服务有些人注销。那么为什么并非所有服务都共享登录令牌验证信息?让SSO服务写,和其他业务阅读。它提醒我sharing the session to implement SSO
。我想如果我可以通过 redis分布式群集分享登录令牌验证信息。但我听说分享会不好?所以为什么?
答案 0 :(得分:0)
SSO服务器是否可以处理那么多请求取决于您的部署。 CAS的部署非常庞大,可处理数十万个请求。它有所不同。
通常,SSO会话与应用程序会话完全分开。一旦您通过SSO登录到应用程序,您就已经为该应用程序建立了一个会话,只要您将其配置为持续,该会话将持续。当它到期时,您的应用程序可能会决定再次对您的SSO服务器进行身份验证。如果SSO服务器仍有SSO会话,它将只重新发出相应的数据,您的应用程序将重新创建会话。如果没有,它将向用户挑战凭证,无论他们是什么,并重做相同的。
应用程序的会话问题完全属于您和应用程序的问题。 SSO服务器永远不应该参与其中。如果您的应用程序需要共享会话,因为它是群集的,那么您应该共享会话。没有人说这是个坏主意。但是,您通常希望确保应用程序尽可能无状态,因为这将使集群部署更容易。
当您从应用程序注销时,您的应用会话已消失,但SSO会话可能仍然存在。因此,您将重新进入应用程序,因为无需提供凭据。如果您愿意,可以退出应用程序和您的SSO服务器。
如果您通过SSO登录了所有其他应用程序,并且您希望通过注销一个来注销,则称为SLO。您的SSO服务器需要联系其为其创建故障单的每个应用程序,并与他们联系以进行注销。或者,您可以销毁所有应用程序的共享会话,假设它们都属于同一套件。