Single Sign-On Server

单点登录系统在企业级Web服务当中非常常见和广泛存在，作为Web软件开发者，即使你没有开发过，肯定也是使用过的。本系列文章将讲述用于Web网站的单点登录系统的CAS协议、原理，以及简单实现。

0.前言和目标

CAS协议是CAS项目（Central Authentication Service）的核心协议，用于构建企业级单点登录服务。

CAS项目是完全开源的一个单点认证系统，但是因为集成了太多组件而导致项目过于复杂和庞大，官方文档讲的也不算特别细致，对于新手来说学习成本非常高。笔者曾基于CAS 5.x的源码做过二次开发定制，用于实际生产应用，个中道路异常坎坷。但实际上我用到的其中的模块其实并不多，只是几个核心模快如CAS单点登录、OAuth2.0授权、OIDC1.0授权、以及LDAP数据源等等，因为项目中子模块众多，一开始也不知道哪些是必须的，所以编译源代码非常耗时，一头扎进源码很难自拔。

反正出于种种原因，以及脑子里一股想折腾和学习（造轮子）的念头，所以决定尝试自己实现最简版的CAS3.0版本的单点登录协议。

1.CAS协议原理

CAS协议 的原理其实在官网的一张图讲得也是比较清晰。

这里我简单叙述一下：

第一阶段：

0.假设上述图中App和App2都集成了CAS-Server的单点登录能力，那么：

1.首先用户通过浏览器访问App时，App服务发现用户未建立登录会话，这时会返回一个302响应，指示跳转到CAS-Server

2.浏览器根据302响应重定向到CAS-Server的登录页面，用户输入进行登录

3.CAS-Server验证密码登录成功后，也会返回302响应，指示跳转回App服务，其中还会携带一个ticket

4.浏览器根据CAS-Server的302响应，携带ticket再重定向到App服务

5.App服务获取这个ticket，通过Http调用CAS-Server提供的/serviceValidate接口进行ticket验证

6.CAS-Server验证ticket有效后，将登录用户名和用户属性返回给App服务

7.APP服务获取到ticket合法响应后，给用户浏览器建立登录会话，并返回用户请求的资源响应

第二阶段：

8.用户再通过浏览器访问App2服务获取资源时，重新开始1流程，但是流程2不会再次要求输入密码，因为用户刚刚已经在CAS-Server登录过了，所以直接返回302响应，指示跳转回App2服务，其中携带一个ticket

9.浏览器根据CAS-Server的302响应，携带ticket再重定向到App2服务

10.App2服务获取这个ticket，通过Http调用CAS-Server提供的/serviceValidate接口进行ticket验证

11.CAS-Server验证ticket有效后，将登录用户名和用户属性返回给App2服务

12.APP2服务获取到ticket合法响应后，给用户浏览器建立登录会话，并返回用户请求的资源响应

2.CAS协议规范

CAS3.0规范 中定义了很多API（包括登录API和代理API），代理API接口我其实用不上，也为了简单起见，所以只实现登录API。

URI	描述
/login	登录
/logout	登出
/validate	服务票据验证 （暂不实现）
/serviceValidate	服务票据验证[CAS 2.0]
/proxyValidate	服务/代理票据验证[CAS 2.0] （暂不实现）
/proxy	代理票据服务[CAS 2.0] （暂不实现）
/p3/serviceValidate	服务票据验证[CAS 3.0]
/p3/proxyValidate	服务/代理票据验证[CAS 3.0] （暂不实现）

接下来我会实现规范表格中的 /login，/logout，/serviceValidate，/p3/serviceValidate接口。