中心认证服务--CAS原理

CAS是Central Authentication Service的首字母缩写，Apereo CAS 是由耶鲁大学实验室2002年出的一个开源的统一认证服务。旨在为 Web 应用系统提供一种可靠的单点登录解决方法。

CAS Architecture

Architecture

从这个图可以看到，CAS服务器端和各种语言的客户端组成了CAS系统体系结构的两个物理组件，它们通过各种协议进行通信。

CAS Server

The CAS server is Java servlet built on the Spring Framework whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. An SSO session is created when the server issues a ticket-granting ticket (TGT) to the user upon successful login. A service ticket (ST) is issued to a service at the user’s request via browser redirects using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. These interactions are described in great detail in the CAS Protocol document.【CAS服务器是构建在Spring框架上的Java servlet，其主要职责是通过发出和验证票据，对用户进行身份验证并授予对启用了CAS的服务(通常称为CAS客户端)的访问权。当服务器向成功登录的用户发出授予票据(TGT)时，将创建SSO会话。服务票证(ST)在用户的请求下通过使用TGT作为令牌的浏览器重定向发送给服务。ST随后在CAS服务器上通过反向通道通信进行验证。这些交互在CAS协议文档中有详细的描述。】

CAS Client

The term “CAS client” has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications in order to communicate with the CAS server via some authentication protocol (e.g. CAS, SAML, OAuth). CAS clients supporting a number of software platforms and products have been developed.【术语“CAS客户端”在通常的使用中有两个不同的含义。CAS客户端是任何启用了CAS的应用程序，可以通过受支持的协议与服务器通信。CAS客户端也是一个软件包，它可以与各种软件平台和应用程序集成，以便通过某些身份验证协议(如CAS、SAML、OAuth)与CAS服务器通信。支持多个软件平台和产品的CAS客户端已经开发完成。】

Supported Protocols

通过任何一种受支持的协议客户端和服务端进行通信。所有这些受支持的协议概念上都是相似的，然后一些协议具有某些特殊的特征，使他们适用于特定的应用或实例。比如，CAS协议支持委托（代理）身份验证，而SAML协议支持attribute release 和单点登出。

CAS proxy 原理图

cas-flow-diagram

上图是CAS官网上的标准流程，具体流程如下：（用户第一次访问受保护的app系统流程）

用户输入GET https://app.example.com/想要访问app系统，由于app系统是需要验证才能范文的，但是app系统在收到该请求的时候并没有发现请求中带有JSESSIONID字段，因此app系统判断发送该请求的用户没有登录认证，最后app系统做出的操作是，重定向该请求，让用户去访问SSO系统，因此我们从图上看到302 Location:https://cas.example.com/cas/login?service=https%3A%2F...这里加上？service=https:%3A%2F... 就是为了方便用户在SSO认证登录后能够再定向到app系统。
用户（或者这里叫Browser）在收到app系统的重定向后，去访问SSO，这个时候SSO发现该用户的请求中没有ticket信息，因此SSO判定该用户还没有在SSO中登录，因此SSO出示login页面，让用户去输入username、password信息。
用户填写username、password信息，SSO系统对其进行认证后，会生成一个ST（Service Ticket）供url上传输 , 并将该用户信息写入SSO的session（session中的用户登录信息是被TGT封装起来的），而这个SSO系统的session的保存是key，value形式的，这个session的key叫做TGC，对应的value值叫做TGT。当重定向回用户时附带ST信息，并且把TGC的值存储到用户的Cookie中。
接下来用户有了ST信息，就拿着这个ST+app系统链接地址（GET https://app.example.com/?ticket=ST-12345678）去访问app系统。
当app系统收到用户的请求时发现，该request中包含ST信息，app系统会去拿着ST信息到SSO进行验证，如果验证通过，SSO返回给app系统success消息（图上是xml信息，还包含其它的可选参数字段信息）。
app系统在得到SSO的肯定回答后，将用户的登录信息存入app系统的session中，此时app系统并没有直接给用户展示要访问的信息，而是把request重定向回用户，只不过redirect 地址中夹带了app系统的session 信息，目的是为了让浏览器存储该session信息到Cookies中，方便后续的二次、三次访问情况。
用户再次根据app系统的redirect 地址（Cookie：JESESSIONID=ABC-1234567 GET https://app.example.com）去请求app系统。
app系统此时收到用户的request是包含JESESSIONID字段的，app系统会在自己的Cookie中验证，如果成功就返回给用户资源信息。

Notes：

- The TGT (Ticket Granting Ticket), stored in the TGC cookie, represents a SSO session for a user.
- The ST (Service Ticket), transmitted as a GET parameter in urls, stands for the access granted by the CAS server to the CASified application for a specific user.

TGC：Ticket Granting Cookie
CAS 会将生成的 TGT 放在 session 中，而 TGC 就是这个 session 的唯一标识(sessionId)，
可以认为是 TGT 的key，为 TGT 就是 TGC 的 value，TGC 以 cookie 的形式保存在浏览器中，
每个请求都会尝试携带 TGC。（每个服务都会在 session 和 cookie 中保存对应的 TGT 和 TGC）

TGT：Ticket Granting Ticket
TGT 是CAS 为用户签发的登录 ticket，也是用于验证用户登录成功的唯一方式。 
TGT 封装了 Cookie 值以及 Cookie 值对应的用户信息，CAS 通过 Cookie 值（TGC）
为 key 查询缓存中有无 TGT（TGC:TGT（key:value）），如果有的话就说明用户已经登录成。

ST：Service Ticket
ST 是当用户访问某一服务时提供的 ticket。用户在访问其他服务时，
发现没有 cookie 或 ST ，那么就会302到 CAS 服务器获取 ST。然后会携带着 ST 302 回来。

用户再次访问app系统的流程：

用户请求app系统链接地址，带上JSESSIONID。
app系统收到带有JSESSIONID的request后，会在app系统的session中查找对应的value，查找成功后向用户发送相应的资源文件。

这个过程比较简单，和普通的请求访问一样，检查服务端是否有存在session值，如果有就直接允许访问相应的资源。

用户第一次访问与 app系统相互信任的系统流程：

用户直接请求app2系统地址链接。https://app2.example.com/
app2系统收到request后发现这个request既没有ST也没有cookie，就会重定向到CAS服务器。
用户的请求被重定向后，去访问CAS服务器，这个时候是带着cookie的。
CAS服务器收到用户带有cookie的request后，根据这个cookie（也就是TGC）去CAS的session中找TGT，如果查找成功，为该用户的请求颁发一个ST，并且更新TGC的值重写回浏览器端，当然CAS服务器端也是需要更新的哈。最后CAS把请求再重定向到app2系统。
用户按照CAS的重定向，携带ST去访问app2系统，app2系统这次发现request带有ST，赶紧去找CAS验证，CAS验证通过后，给app2系统发送确认消息，最后app2系统才给用户返回要访问的资源信息。

老子有个问题哈：CAS是如何验证ST的？看有效期？还是看啥？

参考文章

1. 单点登录（SSO）看这一篇就够了