【原创申明：文章为原创，欢迎非盈利性转载，但转载必须注明来源】
之前写过一篇文章，介绍单点登录的基本原理。这篇文章重点介绍开源单点登录系统CAS的登录和注销的实现方法。并结合实际工作中碰到的问题，探讨在集群环境中应用单点登录可能会面临的问题。
1 单点登录的过程
为了描述方便，假设有如下一个单点登录系统。一套CASServer，两套CAS Client系统。为了描述的方便，省略CAS Server调用用户系统完成登录，以及CASClient从用户系统读取用户详细信息的过程。
1.1多应用情况下Session信息
假定有两个CAS Client应用，一个CAS Server。应用的部署，可能在不同的服务器，也可能有不同的访问IP或域名，即使是同一个浏览器，在各个应用中的Session信息也是不相同的。
浏览器中，每个应用有一个独立的JSESSIONIDCookie。某一个应用，不可能读取到浏览器在其他应用中的Cookie信息。
假定用户首先访问CAS Client 01，系统提醒用户进行一次登录；然后用户访问CAS Client2，不会再提示登录而是直接登录成功。
1.2第一次访问CAS Client 01
用户打开浏览器后第一次访问，重定向到单点登录后，会提示用户输入账号密码登录。登录成功之后，再跳转回CAS Client。
1.3第一次访问CAS Client 02
当用户浏览器已经登录系统，切换到另一个CASClient时，跟第一次访问有所不同，因为已经登录成功，就不会再提醒输入账号密码登录了。
1.4再次访问CAS Clients
当用户已经访问过CAS Client后，当用户再次访问，系统不会再跳转到CAS Server做认证。
1.5CASClient配置
为了实现前述的单点登录过程，以Java WEB项目为例，需要在 web.xml 中进行相应的配置。（为了排版，没有填写Filter的完整class名，请自行查阅补充。）
<filter>
<filter-name>CAS AuthenticationFilter</filter-name>
<filter-class>*.AuthenticationFilter</filter-class>
</filter>
<filter>
<filter-name>CAS Validation Filter</filter-name>
<filter-class>*.Cas10TicketValidationFilter</filter-class>
</filter>
<filter>
<filter-name>CAS HttpServletRequest WrapperFilter</filter-name>
<filter-class>*.HttpServletRequestWrapperFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CAS Validation Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CAS AuthenticationFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CAS HttpServletRequest WrapperFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
仔细看一下配置过滤器可以发现，三个过滤器正好对应流程图中三次访问CAS Client。
- Authentication Filter：负责将未登录用户跳转到登录界面
- Authentication Filter：负责验证Service Ticket
- HttpServletRequest WrapperFilter：负责将用户信息封装到request和session中。
2 统一注销的过程
2.1不能实现统一注销会有什么问题
当用户访问系统后从系统注销，如何能够从每个应用中都注销？注意前面1.4部分的描述，如果用户注销时，并没有注销CASClient 02中的会话信息，如果用户在浏览器中直接访问这个应用，因为Session存在，并不会提醒用户重新登录。
这会带来两个潜在的隐患：
1、 用户注销user1后换账号user2重新登录，进入CAS Client 02之后，当前身份其实还是user1，并没有如用户预期一样使用user2身份。
2、 用户user1点击注销后离开，没有关闭浏览器。这时候其他用户直接打开CAS Client 02，能够直接盗用user1的身份进行操作。
2.2基本概念：TGT和ST
CAS已经考虑到统一注销的问题。
这里有三个重要的概念TGT、ST和Service，需要着重介绍一下，因为它们同后续统一注销的方案息息相关。
2.2.1 Service
这是用户第一次访问CAS Client的URL。假设一个CAS Client应用部署在域名oa.company.com，使用HTTP协议，应用首页是index.htm。当用户第一次访问这个应用时，对应的URL地址是 http://oa.company.com/index.htm 。这个URL，对CAS Server来说，就是一个service。
当用户第一次跳转到CAS Server的时候，可以看到传了一个参数service，就是这个值。当CASServer生成Ticket重定向到CAS Client的时候，实际就是在这个service 中添加了一个参数 ticket 。
2.2.2 TGT：Ticket Grangting Ticket
TGT是CAS Server为每一个登录用户创建的登录令牌。在CASServer上拥有了TGT，用户就可以证明自己在CASServer成功登录过。TGT封装了SessionCookie值以及此Cookie值对应的用户信息。当HTTP请求到来时，CAS以此Cookie值为key查询缓存中有无TGT ，如果有的话，则相信用户已登录过。
2.2.3 ST：Service Ticket
ST是CAS Server为用户签发的访问某一service的认证令牌。用户访问service时，service发现用户没有ST，浏览器会跳转到CASServer去获取ST。CAS Server发现用户有TGT，则签发一个ST，返回给用户。用户使用ST作为ticket参数去访问service，service拿ST去CAS Server验证，验证通过后，得到当前登录用户的登录名。
注意TGT和ST，是一对多的关系。一个TGT会维护一个 services 列表，每当为用户创建一个ST并认证通过后，会将这个ST添加到TGT的services列表中。这样，在CASServer端，这个services列表实际维护了一个用户登录过的所有CASClient。这就为实现统一注销打下了基础。
2.3CAS Client的统一注销配置
CAS Client，为了实现统一注销，除了第一张介绍的三个登录过程的过滤器之外，还需要添加一个统一注销过滤器。
<filter>
<filter-name>CAS Single Sign OutFilter</filter-name>
<filter-class>*.SingleSignOutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CAS Single Sign OutFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class>*.SingleSignOutHttpSessionListener</listener-class>
</listener>
2.4CAS Server注销过程
用户在浏览器中点击“注销”链接，实际浏览器会访问CASServer的注销页面。收到注销请求后，CAS Server会读取到TGT，并检查当前用户登录过的所有service，并依次发送注销请求。
2.5CAS Client注销过程
CAS Client的注销，核心代码是SingleSignOutFilter，它的关键代码
public voiddoFilter(servletRequest, servletResponse, filterChain){
HttpServletRequest request =(HttpServletRequest)servletRequest;
if (handler.isTokenRequest(request)) {
handler.recordSession(request);
} else if (handler.isLogoutRequest(request)) {
handler.destroySession(request);
return;
}
filterChain.doFilter(servletRequest, servletResponse);
}
其中handler是SingleSignOutHandler的实例，这个对象完成用户在CASClient端登录信息的维护和注销工作。
至此，CAS完整的登录和注销过程就完成。
2.6思考：什么情况统一注销会失败
统一注销的实现，需要CAS Server通过HttpClient访问CAS Client的service。如果这个访问过程失败，就会导致统一注销失败。列了几种情况，不详述。
1、开发调试阶段，使用localhost访问CAS Client。
2、CAS Server部署在外网，CAS Client部署在内网。
3、网络安全设置，不允许CASServer访问CAS Client。
3 CAS Client集群的影响
前面的论述，一直假定所有的CAS Client都是单点部署，没有集群。如果集群，会有什么影响，应该如何来解决？
3.1Client集群对登录的影响
假设使用nginx做集群前端，后面部署两台CAS Client 01的实例。我们看看对登录过程会有什么影响。
为了描述方便，CAS Client登录过程会有三次请求（对应三个过滤器），我们依次命名为Authentication Request / Validation Request / Wrapper Request。
Nginx缺省的分发规则，并不是sticky模式，同一个浏览器的请求，会按照nginx自身某种规则进行分发。我们曾经测试过，在双点集群环境下，Authentication Request和ValidationRequest会恰好被分发到两台服务器，这就会导致登录过程死循环。
出现登录死循环的原因，主要在于nginx分发时，没有使用sticky策略，也就是同一个浏览器的请求，永远分发给同一台CAS Client实例。缺省nginx的分发策略，可以根据用户IP分发，实现的是同一个IP永远分发到同一台Client，这样就能解决死循环的问题。
3.2Client集群对注销的影响
当nginx实现了sitcky转发，同一个浏览器的访问会分发到同一个Client1实例，该用户的会话信息也一直保存在Client1实例中。
当用户统一注销时，由CAS Server向Client发送注销请求，这时候nginx无法确保按当前用户进行分发，因此可能会被分发到Client2。这时候，实际效果是注销失败。
这个问题，在我们当前的环境中真实存在，还没有合理的解决方法。初步分析，大概有几个修改方向。
3.2.1 修改nginx分发策略
问题存在的原因，是因为nginx在分发注销策略时，不能准确分发。如果能在这个环节进行修改，系统代码和环境，基本不用做任何修改。
但这个实现难度很大，而且可能会影响nginx的性能。
3.2.2 集群的节点实现Session同步
如果能实现集群Session的同步：同步创建、同步注销，主要在一个Client上实现了注销，其他Client也就同步注销。
这个会对Tomcat性能有影响。
3.2.3 集群节点使用redis保存会话信息
即使是多个节点，它们的会话信息只有一份。一旦失效，则所有节点都失效。这只是一个设想，没有做技术调研，不知能够实现。
3.2.4 每次请求验证用户是否注销
首先，在CAS Server中实现一个接口，用于判断某一个ST对应的TGT是否还有效。
在SingleSignOutFilter中，每次访问都调用CAS Server的这个新接口，判断用户是否已经注销。如果已经注销，则立刻注销本实例中的会话信息。
这个方法是比较安全的解决办法，但每次请求都会调用CASServer接口，会对性能造成巨大影响。完全不建议用这种方案。