CAS SSO服务

Central Authentication Service简称CAS，是一种常见的B/S架构的SSO协议。它的目的是允许一个用户访问多个应用程序，而只需向认证服务器提供一次凭证（如用户名和密码）。这样用户不仅不需在登陆web应用程序时重复认证，而且这些应用程序也无法获得密码等敏感信息。“CAS”也指实现了该协议的软件包。

顾名思义，CAS是一种仅用于Authentication的服务，它和OAuth/OIDC协议不一样，并不能作为一种Authorization的协议。

CAS是由耶鲁大学的Shawn Bayern创始的，后来由耶鲁大学的Drew Mazurek维护。CAS1.0实现了单点登录。 CAS2.0引入了多级代理认证（Multi-tier proxy authentication）。在所有功能中，2.0 版和 3.0 版之间最引人注目的更新是能够在/serviceValidate响应中返回身份验证/用户属性。CAS 服务器在服务器端实现 CAS 协议，甚至可能表现得像 OAuth 提供者、OpenID 提供者或 SAML IdP。

当前CAS改名为Apereo CAS，最新基于Spring Boot的CAS软件版本6.6已发布。

CAS协议

CAS 协议是专门为 CAS 开发的简单而强大的基于票据的协议。完整的协议规范

它涉及一个或多个客户端和一台服务器。
客户端嵌入到经过分类的应用程序（称为“CAS 服务”）中，而 CAS 服务器是一个独立的组件： - CAS 服务器负责对用户进行身份验证并授予对应用程序的访问权限 - CAS 客户端保护 CAS 应用程序并检索用户的身份从 CAS 服务器授予用户。

票据： TGC、TGT 、 ST 、 PGT 、 PGTIOU 、 PT

(1)、TGC（ticket-granting cookie） 授权的票据证明，由 CAS Server 通过 SSL 方式发送给终端用户，存放用户身份认证凭证的Cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CAS Server用来明确用户身份的凭证。

(2)、TGT（Ticket Grangting Ticket） TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成Cookie（叫TGC），写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是Cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的Cookie，则CAS以此Cookie值为key查询缓存中有无TGT ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。

(3)、ST（Service Ticket） ST是CAS为用户签发的访问某一service的票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含Cookie，则CAS会以此Cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。

(4)、PGT（Proxy Granting Ticket） Proxy Service的代理凭据。用户通过CAS成功登录某一Proxy Service后，CAS生成一个PGT对象，缓存在CAS本地，同时将PGT的值（一个UUID字符串）回传给Proxy Service，并保存在Proxy Service里。Proxy Service拿到PGT后，就可以为Target Service（back-end service）做代理，为其申请PT。

(5)、PGTIOU（Proxy Granting Ticket I Owe You） PGTIOU是CAS协议中定义的一种附加票据，它增强了传输、获取PGT的安全性。 PGT的传输与获取的过程：Proxy Service调用CAS的serviceValidate接口验证ST成功后，CAS首先会访问pgtUrl指向的Https URL，将生成的 PGT及PGTIOU传输给proxy service，proxy service会以PGTIOU为key，PGT为value，将其存储在Map中；然后CAS会生成验证ST成功的XML消息，返回给Proxy Service，XML消息中含有PGTIOU，proxy service收到XML消息后，会从中解析出PGTIOU的值，然后以其为key，在Map中找出PGT的值，赋值给代表用户信息的Assertion对象的pgtId，同时在Map中将其删除。

(6)、PT（Proxy Ticket） PT是用户访问Target Service（back-end service）的票据。如果用户访问的是一个Web应用，则Web应用会要求浏览器提供ST，浏览器就会用Cookie去CAS获取一个ST，然后就可以访问这个Web应用了。如果用户访问的不是一个Web应用，而是一个C/S结构的应用，因为C/S结构的应用得不到Cookie，所以用户不能自己去CAS获取ST，而是通过访问proxy service的接口，凭借proxy service的PGT去获取一个PT，然后才能访问到此应用。

TGT、ST、PGT、PT之间关系

ST是TGT签发的。用户在CAS上认证成功后，CAS生成TGT，用TGT签发一个ST，ST的ticketGrantingTicket属性值是TGT对象，然后把ST的值redirect到客户应用。 PGT是ST签发的。用户凭借ST去访问Proxy service，Proxy service去CAS验证ST（同时传递PgtUrl参数给CAS），如果ST验证成功，则CAS用ST签发一个PGT，PGT对象里的ticketGrantingTicket是签发ST的TGT对象。 PT是PGT签发的。Proxy service代理back-end service去CAS获取PT的时候，CAS根据传来的pgt参数，获取到PGT对象，然后调用其grantServiceTicket方法，生成一个PT对象。

Web流程图

代理Web流程图

CAS 协议特点功能之一是 CAS 服务能够充当另一个 CAS 服务的代理，传输用户身份。

评价

CAS协议是一个场景单一的轻量级SSO协议，在迭代版本中又引入其他协议的内容引起杂乱。当前IDaas产品中大多不推荐使用此协议。