1 简介

1.1 概述

本文具体介绍了CAS系统登录认证以及登出认证的过程，以及如何与阿里云账号单点登录体系进行对接，实现两个单点登录系统之间的登录认证。

1.2 术语表

本文档使用的术语如下表：

术语	解释
SSO(Single Sign On)	单点登录服务器
TGC(Ticket-granting cooki）	存放用户身份认证凭证的 cookie ，在浏览器和SSO间通讯时使用，并且只能基于安全通道传输（ Https ），是服务器用来明确用户身份的凭证
ST(ServiceTicket）	服务票据，服务的惟一标识码 , 由 SSO发出（ Http 传送），通过客户端浏览器到达业务服务器端；一个特定的服务只能有一个惟一的 ST ；
TGT(TicketGrangtingTicket)	票据授权票据，由 AS 发放。即获取这样一张票据后，表示用户已经登录SSO；
AS(Authentication service)	(认证用服务，存放用户信息，发放 TGT) ；

1.3 参考资料

编写此文档时参考的资料如下：

2 登录流程

2.1 单点登录时序图

下图展示了CAS系统登录的整个过程

2.2 单点登录流程

2.2.1 未登录SSO流程

下图为用户未登录SSO系统，访问对接SSO应用A的登录场景

用户访问应用A
应用A的将用户的请求通过浏览器重定向到SSO，并且在重定向访问请求的参数中带上应用A的访问地址，当用户登录单点登录服务器时可以返回到应用A
浏览器通过重定向访问到SSO
SSO将登录界面返回给用户
用户输入登录信息
SSO通过统一用户系统验证用户的信息正确后，在通过浏览器重定向返回到应用A。此时，SSO已经生成了用户相关的TGT票据，并且将TGT对应的TGC存放到浏览器Cookie中。SSO可以访问浏览器Cookie中的TGC来判断当前用户是否登录。SSO会根据TGT生成一个ST票据，并将ST票据通过重定向传给应用A。
浏览器重定向访问到应用A
应用A从访问地址中拿到ST票据，此时应用A通过转发的方式将票据传送给SSO来校验ST获取用户信息。
SSO校验ST真实性后，将用户信息返回给应用A，应用A将用户信息绑定在session中，当用户下次访问应用A时，应用A检测session中是否存在，如果存在将不会再访问SSO。

2.2.2 已登录SSO流程

下图为用户已经在浏览器中登录SSO系统，访问对接SSO应用B系统的场景

流程与2.2.1章节基本相同，只是在3-4步骤中，SSO检测是否存在TGC，如果存在TGC，会根据TGC找到对应TGT票据，然后通过TGT生成ST票据重定向返回给应用A。

2.3 REST服务登录

CAS协议只能够满足B/S架构的系统，对于C/S模式的系统，需要开发新的接口来实现。CAS的扩展功能中有相关的实现，其中一种就是REST服务。

REST服务将CAS登录流程中的几个步骤抽象成了URI，每个URI代表了一个接口，通过调用这些接口来获取对应得数据。REST服务是通过http通信协议完成的，所以不用关注用什么语言实现，从而使不同语言，架构的系统能够进行数据交换。下图是C/S应用通过REST服务进行登录的时序图：

整体流程与2.2.1大致相同，C/S架构登录时，没有通过浏览器访问应用，所以TGC保存在PC客户端中，在REST服务中将返回TGC给应用。当用户再次登录PC端应用时，应用将TGC通过接口发送给SSO，SSO会根据发送的TGC找到对应TGT，然后生成ST票据返回给PC端应用，之后获取用户凭证步骤与2.2.1章节相同。

2.4 阿里云账号对接

对接阿里云分别使用了两种协议，SAML协议用于公有云环境，OAuth用于专有云环境。

2.4.1 SAML对接

SAML是一种基于XML的认正规范，由IDP(身份认证方)和SP(服务方)组成。在与阿里云对接的场景中，SSO相等于IDP，阿里云控制台相当于SP。CAS支持SAML协议，但是没有IDP的实现方法，所以通过引入shibboleth的开源IDP系统与阿里云进行对接。时序图如下所示：

用户尝试访问SP。
SP生成一个 SAML 身份验证请求。SAML 请求将进行编码并嵌入到SSO 服务的网址中。包含用户尝试访问的 SP应用程序的编码网址的 RelayState 参数也会嵌入到 SSO 网址中。该 RelayState 参数作为不透明标识符，将直接传回该标识符而不进行任何修改或检查。
SP将重定向发送到用户的浏览器。重定向网址包含应向SSO 服务提交的编码 SAML 身份验证请求。
IDP（统一认证中心或叫Identity Provider）解码 SAML 请求，并提取 SP的 ACS（声明客户服务）网址以及用户的目标网址（RelayState 参数）。然后，IDP作为一个SSO的对接应用，重定向到SSO对用户进行身份验证。SSO通过检测浏览器的TGC来判断用户是否登录。
IDP生成一个 SAML 响应，其中包含经过验证的用户的用户名。按照 SAML 2.0 规范，此响应将使用统一认证中心的 DSA/RSA 公钥和私钥进行数字签名。
IDP对 SAML 响应和 RelayState 参数进行编码，并将该信息返回到用户的浏览器。IDP提供了一种机制，以便浏览器可以将该信息转发到 SP。SP使用IDP的公钥验证 SAML 响应。如果成功验证该响应，ACS 则会将用户重定向到目标网址。
用户将重定向到目标网址并登录到 SP。

2.4.2 OAuth2.0对接

OAuth2.0是一种权限认证协议，用于客户端与第三方应用直接的获取受限制资源的认证协议。该协议定义了认证的整个流程所需要的接口和认证过程中传输的参数。认证过程如下图所示：

用户打开客户端以后，客户端要求用户给予授权。
用户同意给予客户端授权。
客户端使用上一步获得的授权，向认证服务器申请令牌（access token）。
认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
客户端使用令牌，向资源服务器申请获取资源。
资源服务器确认令牌无误，同意向客户端开放资源。

OAuth2.0的认证方式和cas有些相同，在这个对接方案中，需要sso充当认证服务器，提供申请令牌。SSO将TGT当做申请令牌access token发送给对接服务，然后对接服务通过该令牌来获取用户信息。具体流程如下图所示：

3 登出流程

单点登录为保证用户账号信息的安全，需要在用户登出一个应用时，同时通知其他已登录的应用，确保所有对接SSO应用登出。

3.1 后置登出

后置登出时SSO将登出请求直接发送给各个应用，流程图如下图所示：

用户进行登出操作，向SSO发送登出请求
SSO检测浏览器中的TGC，并根据TGC获取TGT，清除TGC和TGT。
在清除TGC、TGT同时，取出TGT中存放的已登录应用地址，将登出请求分发给各个应用。
应用接收到登出请求后，删除session，session中保存用户信息。

3.2 前置登出

前置登出时，考虑到负载均衡的情况下，无法将请求准确的发送给对应应用所在的服务器，采取浏览器重定向的方式发送请求给应用，流程图如下所示：

与前置登出不同，3.1后置登出将登出请求直接发送给应用。前置登出通过重定向依次发送请求通知应用登出，所以SSO必须等待前一个应用登出完成返回响应后才能够通知下一个应用登出。这个登出方式适用于负载均衡情况下，同一个浏览器只能够访问负载均衡设备背后的同一台服务器，这样就能保证应用接收到登出请求。

4 安全性分析

在整个登录过程中，主要使用的凭据为ST和TGC（相关介绍参考1.2参考术语表），SSO通过TGC判断用户是否登录，通过ST判断是否将用户信息发给对应应用。

4.1 ST的安全性分析：

ST作为应用端票据，SSO发送的ST只有对应应用使用有效，
基于随机数生成，防止ST被伪造。
使用后作废
票据有效期为10s。

4.2 TGC的安全性分析：

TGC作为识别用户登录的凭证，存放在浏览器中，为了防止TGC被窃取，与SSO的所有通信都必须通过安全通道（即TLSv1）进行，保证的TGC被窃取的难度，防止在传输过程中凭据被篡改。
TGC的内容经过自定义的证书签名加密的，无法仿造和篡改。
服务器获取TGC会进行IP校验，来检测TGC的真实性。

4.3 客户端session安全性分析

当应用通过ST获取到session时，访问不需要在经过SSO。应用通过对接单点登出，在登出SSO后，清空对接应用对应session的用户信息，防止登录后仍能够获取用户信息。

5 其他单点登录方案比较

拿OAuth2.0与CAS，OAuth2.0协议只实现了第三方应用对于资源的认证，但是协议本身没有涉及会话状态的保持，需要客户端和服务器自行约定规则。CAS规定了服务器和客户端如何保持登录状态，从而实现用户在访问多个应用时，只需要进行一次登录。
SAML和CAS相比较，SAML因为是基于xml交互的协议，所以传输内容多，并且内容进行了非对称加密，在传输过程中更加安全，但是十分复杂并且传输内容多，性能上会有影响。
CAS与传统单点登录相比较，传统单点登录系统实现单点登录是基于session认证的，session只能在同一子域名才能够允许访问。CAS将认证信息TGC保存在cookie中，然后定义了客户端应用免登录获取用户信息的流程，让客户端应用将用户信息保存在其自身服务器的session，这样减轻了SSO服务器的负担，也解决了非同子域名下单点登录的问题。

单点登录介绍