CAS实战の简介
一、SSO简介
单点登录的英文名称为Single Sign-On，简写为SSO，它是一个用户认证的过程，允许用户一次性进行认证之后，就访问系统中不同的应用；而不需要访问每个应用时，都重新输入密码。IBM对SSO有一个形象的解释“单点登录、全网漫游”。
二、SSO体系角色：
1、 User （多个）
2、 Web 应用（多个）
3、 SSO 认证中心（ 1 个 ）
三、CAS实现原理和机制
- 首先，单点登录分为“服务端”和“客户端”。服务端就是单点登录服务器，而客户端通常是“函数库”或者“插件”。需要使用单点登录的应用程序，需要把客户端插件安装到自己的系统中，或者将客户端函数库包括在代码中。单点登录的客户端通常替换了原来应用程序的认证部分的代码。
- 某个应用程序首先要发起第1次认证。大部分情况下，应用程序中嵌入的客户端会把应用程序原来的登录画面屏蔽掉，而直接转到单点登录服务器的登录页面。
- 用户在单点登录服务器的登录页面中，输入用户名和密码。
- 然后单点登录服务器会对用户名和密码进行认证。认证本身并不是单点登录服务器的功能，因此，通常会引入某种认证机制。认证机制可以有很多种，例如自己写一个认证程序，或者使用一些标准的认证方法，例如LDAP或者数据库等等。在大多数情况下，会使用LDAP进行认证。
- 认证通过之后，单点登录服务器会和应用程序进行一个比较复杂的交互，这通常是某种授权机制。CAS使用的是所谓的Ticket。
- 授权完成后，CAS把页面重定向，回到Web应用。Web应用此时就完成了成功的登录（当然这也是单点登录的客户端，根据返回的Ticket信息进行判断成功的）。
- 然后单点登录服务器会在客户端创建一个Cookie。注意，是在用户的客户端，而不是服务端创建一个Cookie。这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。
- 如果用户此时希望进入其他Web应用程序，则安装在这些应用程序中的单点登录客户端，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。登录之后，CAS重定向回到用户的应用程序。
这样，就不再需要用户继续输入用户名和密码，从而实现了单点登录。
注意，这种单点登录体系中，并没有通过http进行密码的传递（但是有用户名的传递），因此是十分安全的。
四、项目实战
1、公司业务系统架构图：
2、具体实现流程图：
实现步骤：
用户访问业务系统（客户端，如图中systemA），先检查过滤器（有些请求路径是httpclient接口，必须过滤掉），然后判断客户端是否存在service ticket（票据），如果存在，则跳转回到客户端，如果不存在，则重定向到cas server（认证中心）进行认证，认证成功后，cas server生成一个service ticket并缓存下来，与此同时service ticket被存与cookie中种在客户端浏览器中，以备下次客户端访问识别。
3、登录流程图：
先读取DB账户信息，如成功，则直接进入客户端A；如失败，再读取AD域中用户信息，如成功，则将账户信息同步到DB；如失败，则弹出失败提示。
4、同步
当时业务设计的是，客户端拥有自身的用户信息表（由于权限的需要），所以新增了一份工作--将AD域中的账户信息同步到cas server 账户信息表，再同步到cas clinet账户信息表。
（1） cas server同步AD域账户数据
频率：一天一次
Step1: 先查询出AD域下所有账户，再查询出cas server下的所有账户；
Step2: AD域下所有账户与cas server下的所有账户匹配；
Step3: AD域下有的账户，cas server下不存在，则对cas server进行账户添加；AD域下没有的账户，cas server下存在，则对cas server进行账户删除；AD域下有的账户，cas server也存在，则不做处理。
Tips:以userName,isDelete作为联合主键
（2）cas client同步cas server账户数据
频率：一天一次
Step1: 先查询出cas client下所有账户，再查询出cas server下的所有账户；
Step2: cas client下所有账户与cas server下的所有账户匹配；
Step3: cas client下有的账户，cas server下不存在，则对cas client进行账户删除；cas client下没有的账户，cas server下存在，则对cas client进行账户添加；cas client下有的账户，cas server也存在，则不做处理。
Tips:以userName,userRealName,isDelete作为联合主键
