一、做法
问题:浏览器将cas server 签发的ticket 传给webapp后端,webapp后端向cas server 验证通过后,是webapp后端自己用 session 管理用户缓存就行,然后后续不需要经过 cas server。还是说每次都需要重新向 cas server 验证?
回答:
在使用 CAS (Central Authentication Service) 进行单点登录 (SSO) 时,通常的流程如下:
-
用户通过浏览器访问 Web 应用: 用户首次访问 Web 应用时,如果用户没有登录,Web 应用会将用户重定向到 CAS Server 进行身份验证。
-
CAS Server 进行身份验证: 用户在 CAS Server 上输入凭据(如用户名和密码)进行身份验证。
-
CAS Server 签发 TGT 和 Service Ticket (ST): 验证通过后,CAS Server 会签发一个 Ticket Granting Ticket (TGT) 给用户,并且为 Web 应用生成一个 Service Ticket (ST)。
-
Web 应用验证 Service Ticket: 浏览器携带 ST 返回 Web 应用,Web 应用将这个 ST 发送给 CAS Server 进行验证。
-
CAS Server 验证 ST 并返回用户信息: CAS Server 验证 ST 并返回用户的身份信息给 Web 应用。
-
Web 应用创建会话 (Session): Web 应用使用接收到的用户信息创建一个本地会话(session),然后将会话标识(如 Cookie)返回给用户的浏览器。
在这个流程中,Web 应用后端自己用 session 管理用户缓存是常见且推荐的做法。具体步骤如下:
- 一旦 Web 应用从 CAS Server 成功验证了 ST,并获取到用户信息后,Web 应用通常会在其自己的服务器上创建一个 session 来管理用户的登录状态。
- 这个 session ID 会通过 Cookie 等机制返回给用户的浏览器。
- 在用户后续的请求中,浏览器会携带这个 session ID,Web 应用可以通过 session ID 来验证用户的登录状态,而不需要每次都重新向 CAS Server 验证。
这样做的好处是减少了对 CAS Server 的依赖和网络开销,同时也提高了系统的性能。
总结:
- Web 应用在首次接收到并验证通过 CAS Server 签发的 Service Ticket 后,会创建一个本地 session 来管理用户的登录状态。
- 在用户的后续请求中,Web 应用可以通过 session 来验证用户,无需每次都重新向 CAS Server 进行验证。
这种机制确保了用户在登录后的访问效率,同时保持了一定的安全性。
网友评论