SSO，未知
我开始为我们生产的3个不同的webapps开发SSO解决方案，并且仍然为同一个客户端维护。
事实上，所有3个人通过第四个单独的应用程序将他们的用户和登录信息存储在同一个地方，该应用程序只提供基本的restful api服务。 这基本上意味着当一个人试图登录时，我们实际上会调用其他服务来询问这个用户名和密码是否正确。
在某种程度上，这第四个宁静的东西已经完成了至少一半我们需要的工作。
我们现在需要的是一种方法，让用户登录webapp A，然后按照链接（或简单地键入其URL）到webapp B（或简单地键入其URL）并到达那里已经记录 （或反之亦然）。
我一直在阅读很多有关CAS和openID甚至是oauth的内容，但我无法真正决定它。 这种模式是集中的吗？ 分散的？
我的一万英尺的视图表明，我会以某种方式只需要将这个“缺失的function”添加到我们的restful api服务器中。
但是怎么样？
ps：这3个完全分开。 部署在不同的机器上（其中2台在glassfish上运行，另一台在tomcat上运行）。 也是不同的领域。
pps：它们都是弹簧驱动的webapps（因此它们使用spring-security ）
ppps：截至今天，还有其他webapps使用我们的restul api（非spring，非java）。 这个解决方案可能必须准备好处理这些。
是的，听起来你需要一个“真正的”单点登录系统，而不仅仅是一个集中的凭证存储库。 正如您所提到的，有几种选择：
-
OpenId – 更适合于您希望允许用户使用由第三方维护的凭据登录系统的Internet类型应用程序。 Stackoverflow是一个典型的例子。 您可以使用Google帐户登录等。
-
Oauth提供伪认证和sso – 而OpenId说“这是用户x”oauth说“这个用户可以访问x的信息”……所以你可以假设用户是x。
-
CAS ， Cloudseal ， OpenAM等都提供真正的单点登录，适用于内部网或外部网环境。 CAS和Cloudseal有特别好的Spring支持。
- 可信站点（白名单中的依赖方（RP） – 在您的情况下为app a，b，c）使用返回URL向主站点（提供者 – “第四个单独的应用程序”）发出请求（重定向）。
- 主站点确保请求（returnURL）来自域名的白名单
- 记录用户（如果未记录，显示登录表单），将用户标记为登录数据库并将临时令牌添加到用户数据库。
- 主站点使用令牌返回（重定向）到RP。
- RP使用令牌查看数据库，记录用户并删除令牌。
SSOff也很简单：只需将用户数据库中的每个请求检查到bool记录（userLogged）即可。 没有重定向。 注销时只需将记录（userLogged）更改为false，每个站点都会知道。