SSO,未知

时间:2012-04-14 10:01:34

标签: java spring-security single-sign-on cas

我开始为我们制作的3个不同的网络应用程序开发 SSO 解决方案,并且仍然为同一个客户端维护。

事实上,所有3个人通过第四个单独的应用程序将他们的用户和登录信息存储在同一个地方,该应用程序只提供基本的restful api服务。 这基本上意味着当一个人试图登录时,我们实际上会调用其他服务来询问这个用户名和密码是否正确。

在某种程度上,这第四个宁静的东西已经至少我们需要的工作的一半。

我们现在需要的是让用户登录webapp A,然后按照链接(或简单地键入其URL)到webapp B(或只是输入其URL)并且已经记录(或反之亦然)。

我一直在阅读很多关于 CAS openID 甚至 oauth 的内容,但我无法真正决定它。 这个模式是集中的吗?分散?

我的一万英尺的视图表明我不知何故只需要将这个“缺失的功能”添加到我们的restful api服务器中。

但是怎么样?

ps:这3个完全分开。部署在不同的机器上(其中2台在glassfish上运行,另一台在tomcat上运行)。不同的领域。

pps:他们都是弹簧驱动的webapps(因此他们使用 spring-security

ppps:截至今天,还有其他的webapps使用我们的restul api(非spring,非java)。 这个解决方案可能必须准备好处理它们。

2 个答案:

答案 0 :(得分:4)

是的,听起来你需要一个“真正的”单点登录系统,而不仅仅是一个集中的凭证存储库。正如您所提到的,有几种选择:

  1. OpenId - 更适合您的互联网类型应用程序 希望允许用户使用凭据登录您的系统 由第三方维护。 Stackoverflow是一个典型的例子。 您可以使用Google帐户等登录。

  2. Oauth提供伪认证和sso - 而OpenId说 “这是用户x”oauth说“这个用户有权访问x 信息“......所以你可以假设用户是x。

  3. CASCloudsealOpenAM等都提供了真正的单身 登录并适用于Intranet或Extranet环境。 CAS和Cloudseal都有特别好的Spring支持。

答案 1 :(得分:0)

  • 可信站点(白名单中的依赖方(RP) - 在您的情况下为app a,b,c)使用返回URL向主站点(提供者 - “第四个单独的应用程序”)发出请求(重定向)。
  • 主站点确保请求(returnURL)来自白名单域名
  • 记录用户(如果未记录,显示登录表单),将用户标记为登录数据库并将临时令牌添加到用户数据库。
  • 主站点返回(重定向)到带有令牌的RP。
  • RP使用令牌查看数据库,记录用户并删除令牌。

SSOff也很简单:只需将用户数据库中的每个请求检查到bool记录(userLogged)。没有重定向。注销时只需将记录(userLogged)更改为false,每个站点都会知道。