美文网首页
前后端与 Cas 集成,以及后端的做法。

前后端与 Cas 集成,以及后端的做法。

作者: 放开那个BUG | 来源:发表于2024-05-28 23:11 被阅读0次

    一、做法

    问题:浏览器将cas server 签发的ticket 传给webapp后端,webapp后端向cas server 验证通过后,是webapp后端自己用 session 管理用户缓存就行,然后后续不需要经过 cas server。还是说每次都需要重新向 cas server 验证?

    回答:
    在使用 CAS (Central Authentication Service) 进行单点登录 (SSO) 时,通常的流程如下:

    1. 用户通过浏览器访问 Web 应用: 用户首次访问 Web 应用时,如果用户没有登录,Web 应用会将用户重定向到 CAS Server 进行身份验证。

    2. CAS Server 进行身份验证: 用户在 CAS Server 上输入凭据(如用户名和密码)进行身份验证。

    3. CAS Server 签发 TGT 和 Service Ticket (ST): 验证通过后,CAS Server 会签发一个 Ticket Granting Ticket (TGT) 给用户,并且为 Web 应用生成一个 Service Ticket (ST)。

    4. Web 应用验证 Service Ticket: 浏览器携带 ST 返回 Web 应用,Web 应用将这个 ST 发送给 CAS Server 进行验证。

    5. CAS Server 验证 ST 并返回用户信息: CAS Server 验证 ST 并返回用户的身份信息给 Web 应用。

    6. 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 进行验证。

    这种机制确保了用户在登录后的访问效率,同时保持了一定的安全性。

    相关文章

      网友评论

          本文标题:前后端与 Cas 集成,以及后端的做法。

          本文链接:https://www.haomeiwen.com/subject/jmukqjtx.html