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接口。