主题
CAS协议说明
CAS（Central Authentication Service）认证是一种基于Web的单点登录（SSO）协议，它允许用户在多个应用系统中进行一次认证后，便可访问所有参与认证的应用系统，而无需重复登录。CAS的核心原理是将身份认证的任务集中到一个认证服务器上，由该服务器来负责用户的身份验证，而其他应用系统（服务端）则依赖认证服务器进行授权。 在CAS 协议中，涉及到两个主体。CAS Server 和 CAS Client。这两个主体通过用户浏览器进行信息交换。方式上，比如 CAS Client 可以返回带参数的重定向，将信息转发给 CAS Server。登录验证成功后 CAS Server 会返回CAS Client一个包含用户信息的 XML 或 JSON， CAS Client验证用户信息后会返回给用户访问资源。
基本原理
认证流程
- 用户试图登录 CAS Client 提供的应用。
- CAS Client 会分析该请求的 Http 请求中是否包含认证票据ST，如果没有，则说明当前用户尚未认证，于是重定向 CAS Server ,并传递 Service（也就是要访问的目的资源地址）。
- 用户输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 票据 ST，然后附带生成的ST重定向到 CAS client。
- CAS Client 在拿到 Service 和新产生的 ST 过后，通过后台与 CAS Server 进行交互验证。
- CAS Server 根据请求参数 Service 和 ST 进行身份核实，以确保 ST 的合法性，并返回一段指定格式的 XML（包含用户信息）给 CAS Client。
- CAS Client 和CAS Server之间完成了一个对用户的身份核实，返回给用户CAS Client访问资源。
票据说明
- TGC（ticket-granting cookie）：授权的票据证明，由 CAS Server 通过发送给终端用户，存放用户身份认证凭证的Cookie，在浏览器和CAS Server间通讯时使用，是CAS Server用来明确用户身份的凭证。
- 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 ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。
- 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验证，验证通过后，允许用户访问资源。
开发步骤
步骤一：实现“认证登录”API接口
步骤二：实现“注销登录”API接口
提示
若不使用CAS SDK集成，则实现步骤略有不同，需要自行实现CAS协议中的相关接口逻辑。
API列表
| 名称 | 说明 | 版本 |
|---|---|---|
| 认证登录 | 用户访问集成应用时，应用向IDS发起基于CAS的认证登录（重定向方式） | |
| 注销登录 | 注销CAS登录的统一认证会话 |