春季单点登录(SSO)情况下的CAS工作流程



我想知道CAS是如何工作的(需要工作流程)。想象一下:

  1. 用户在App1上通过CAS身份验证(例如,example.com/App1)
  2. 用户转到另一个应用程序(例如.com/app2)

每个应用程序都必须在页面顶部显示用户名。他们是怎么知道的?在只有一个应用程序的情况下,工作流程非常清晰:

  1. App1:当用户在没有身份验证的情况下浏览页面时,只需将"登录"链接显示为用户名
  2. 应用程序1:用户一度按下"登录">
  3. 应用程序1:将用户重定向到CAS
  4. CAS:请求用户登录/通过
  5. CAS:用户输入登录/通行证
  6. CAS:将用户重定向回App1
  7. App1:从CAS获取令牌和用户名(或ID),并赋予该用户一些权限。完成

但是现在:App2(App3等等)如何知道用户已经通过了身份验证?他们是否都必须将用户从每个页面重定向到CAS,只是为了知道用户是否已经通过身份验证并请求其姓名?

在Spring的情况下,它将是一个巨大的重定向,而我有一些独立的应用程序,如:

example.com/App1
example.com/App2
...
example.com/AppN

我还没有10个信誉,所以你需要在检查工作流图像

http://idms.rutgers.edu/cas/how_does_it_work.shtml

当新用户最初登录到应用程序时,他们不会与该应用程序建立会话。应用程序(通过CAS客户端)将浏览器重定向到CAS登录页面,而不是显示要求输入用户名和密码的登录表单。

然后CAS对用户进行身份验证。如果身份验证失败,将再次显示CAS登录页面并显示错误消息。因此,在身份验证成功之前,用户将不会返回到应用程序。如果用户当时不确定如何继续,CAS登录页面上会有帮助台链接。一旦用户成功验证,CAS将把浏览器重定向回您的应用程序。CAS通过附加到CAS登录url的{服务}参数知道重定向到何处。

当CAS将经过身份验证的用户重定向回您的应用程序时,它将在您的url中附加一个{ticket}参数。

返回到应用程序的票证是不透明的,这意味着除了CAS服务器之外,它不包括对任何人有用的信息。您的应用程序唯一能做的就是将此票证发送回CAS进行验证。

然后,CAS将响应此票证不代表此服务的有效用户,或确认此票证证明了身份验证。在后面的情况下,CAS还将提供用户名,以便您知道用户的身份。

应用程序必须提供自己的会话管理。一旦用户通过身份验证,您的应用程序就应该在会话中跟踪这一事实,这样您就不必使用CAS服务器重新对其进行身份验证。通常情况下,这与直接从应用程序验证用户的情况相同。

每个应用程序都应该提供自己的注销功能,这将使会话无效,并要求用户重新验证到应用程序中。请注意,如果他们通过myRutgers门户使用SSO,则无需重新输入用户名和密码。

使用CAS意味着CAS服务器跟踪哪个用户进行了全局身份验证(使用存储Ticket Granting Ticket Id-TGT的cookie)。每个应用程序都必须维护自己的机制来对主会话和相应的信息进行关键跟踪。

因此,如果用户想要访问安全应用程序APP1(并且未通过身份验证),他将被重定向到CAS-Server。在不发送有效TGT的情况下,将呈现登录表单,否则(或在成功向CAS-Server验证后)将生成服务票证(ST),该服务票证必须呈现给APP1。在这里,此服务票证将根据CAS-服务器进行验证(使用服务器到服务器通信)-如果有效,则返回用户ID(可能还有其他信息)。现在由应用程序APP1根据用户ID创建主体并提供授权信息(例如,CAS-Server根据LDAP进行认证,而APP1将用户数据存储在数据库中)。对APP1的所有后续请求都不应再涉及CAS-服务器。

如果用户向APP2发出请求,则上述过程将再次启动。

L'sync,

你有没有试着把你的问题发布给cas用户[cas-user@lists.jasig.org]邮件列表?

在过去的6个月里,我一直在与CAS合作,据我所知,App2(App3等)在没有重定向到CAS的情况下无法了解用户属性。

通过将用户属性与网络会话一起存储和/或在显示登录名的页面中嵌入iframe-header,可以避免将App2的所有页面置于CAS筛选器之后。

Marvin是CAS的贡献者,他在GitHub上维护了一个出色的CAS客户端测试网络应用程序,在那里你可以看到他是如何读取用户属性的。https://github.com/serac/java-cas-client-test

最新更新