三方系统接入认证平台参考指南

轻码猿2023年1月14日大约 8 分钟

单点登录主要用于多系统集成，即在多个系统中，用户只需要到一个中央服务器登录一次即可访问这些系统中的任何一个，无须多次登录。

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

接入文档目录（仅提供CAS Client端的接入说明）

单点登录的解决方案

目前已经有了成熟的单点登录实现方案，比如CAS，我们只要在web系统中应用单点登录方案CAS即可。(主要涉及到注册登录验证等模块的改动)。

一、CAS简介

CAS (Central Authentication Service) 是耶鲁大学（Yale University）发起的一个java开源项目，
旨在为 Web应用系统提供一种可靠的单点登录解决方案（ Web SSO ）， CAS 具有以下特点：

开源的企业级单点登录解决方案；
CAS Server 为需要独立部署的 Web 应用----一个独立的Web应用程序(cas.war)；
CAS Client 支持非常多的客户端 ( 指单点登录系统中的各个 Web 应用 ) ，包括 Java, .Net, PHP, Perl等。

CAS资源链接：

github：https://github.com/apereo/cas
下载链接：https://www.apereo.org/projects/cas/download-cas

二、CAS原理

从结构上看，CAS有两部分构成，包括服务端（CAS Server）以及客户端（CAS Client）。

CAS结构图如下：

1.CAS Server

CAS Server 需要独立部署，主要负责对用户的认证工作，它会处理用户名/密码等凭证 (Credentials)
CAS Server 负责完成对用户的认证工作，需要独立部署。并且有不止一种 CAS Server 的实现， Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。
CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方式，
CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。

2.CAS Client

CAS Client 部署在客户端，负责处理本地 Web 应用（客户端）受保护资源的访问请求，并且当需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。
CAS Client 负责部署在客户端（注意，是指 Web 应用），原则上， CAS Client 的部署意味着，当有对本地 Web 应用的受保护资源的访问请求，
并且需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。
目前， CAS Client 支持（某些在完善中）非常多的客户端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客户端，
几乎可以这样说， CAS 协议能够适合任何语言编写的客户端应用。

3.CAS 相关词汇介绍

TGC(ticket-granting cookie) —— 授权的票据证明，由 CAS Server 通过 SSL 方式发送给终端用户；
KDC( Key Distribution Center ) —— 密钥发放中心；
ST (Service ticket) —— 服务票据，由 KDC 的 TGS 发放， ST 只能被尝试验证一次。任何一台 Workstation 都需要拥有一张有效的 Service Ticket 才能访问域内部的应用 (Applications) 。
如果能正确接收 Service Ticket ，说明在 CASClient-CASServer 之间的信任关系已经被正确建立起来，通常为一张数字加密的证书；
TGT(Ticket Granting tieckt) —— 票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，
以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交 Credentials （凭证或身份认证信息 ) ；
AS (Authentication Service) —— 认证服务，索取 Crendential ，发放 TGT ；
TGS (Ticket-Granting Service) —— 票据授权服务，索取 TGT ，发放 ST 。

4.CAS 协议和工作流程

CAS 基础协议如下图：

CAS 工作流程：

1.CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，
CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket （ ST ）和 Ticket Granting tieckt(TGT) ，
如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），
以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，
并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ），
CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5 ， 6 步中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
2.在该协议中，所有与 CAS 的交互均采用 SSL 协议确保 ST 和 TGC 的安全性。协议工作过程中会有两次重定向的过程，
但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
3.CAS 如何实现 SSO
当用户访问另一服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的第四步，达到了 SSO 的效果；
如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的第三步) 。
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。

5.CAS 的验证流程

（1）用户浏览受系统保护的URL。
（2）CAS Client服务端收到请求，Filter拦截该请求，在Filter中判断该用户是否已经登陆，如果已经登陆，就直接进入系统，否则，
将请求转发到CAS Server服务端的LoginURL。
（3）在LoginURL中会获取到用户的Cookie，检验用户是否已经在其他相关使用SSO的系统登陆成功。如果已经在其他的系统登陆了，则将请求转回 CAS Client，
并且带回一个ticket, CAS Client再次发送请求到ValidateURL。否则，系统提示用户输入ID和PASSWORD。
（4）提交后请求到ValidateURL，CAS Server验证ticket的有效性。然后返回结果给CAS Client。
如果ticket有效，则CAS Client应让该用户浏览受保护的资源。否则，重定向到登陆页面，提示用户输入ID和PASSWORD。
（5）校验ID和Password是否匹配。如不匹配，再次要求用户输入ID和PASSWORD。否则，CAS Server记录用户登陆成功。并向浏览器回送Cookie，
记录用户已经登陆成功。如果浏览器不支持Cookie，则无法实现单点登陆。

6.CAS 用户访问流程实例

用户第一次访问一个CAS 服务的客户web 应用时（例如访问URL ：http://10.10.10.55:8081/web1 ），部署在客户web 应用的cas AuthenticationFilter ，
会截获此请求，生成service 参数，然后redirect 到CAS 服务的login 接口，url为 https://10.10.10.103:8014/login?service=http%3A%2F%2F192.168.1.90%3A8081%2Fweb1%2F ，
认证成功后，CAS 服务器会生成认证cookie ，写入浏览器，同时将cookie 缓存到服务器本地，CAS 服务器还会根据service 参数生成ticket，
ticket 会保存到服务器，也会加在url 后面，然后将请求redirect 回客户web 应用，url 为http://10.10.10.55:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZuMwnbMvxpCBcNAIi6-20 。
这时客户端的AuthenticationFilter 看到ticket 参数后，会跳过，由其后面的TicketValidationFilter 处理，
TicketValidationFilter 会利用httpclient 工具访问cas 服务的/serviceValidate 接口,
将ticket 、service 都传到此接口，由此接口验证ticket 的有效性，TicketValidationFilter 如果得到验证成功的消息，
就会把用户信息写入web 应用的session里。
至此为止，SSO 会话就建立起来了，以后用户在同一浏览器里访问此web 应用时，
AuthenticationFilter 会在session 里读取到用户信息，所以就不会去CAS 认证，
如果在此浏览器里访问别的web 应用时，AuthenticationFilter 在session 里读取不到用户信息，
会去CAS 的login 接口认证，但这时CAS 会读取到浏览器传来的cookie ，所以CAS 不会要求用户去登录页面登录，
只是会根据service 参数生成一个ticket ，然后再和web 应用做一个验证ticket 的交互。