usmssosetup 单点登录被禁用_SSO(单点登录)实施中遇到的几个问题

单点登录应用中，遇到如下的几个问题：1.超时问题；2.jsessionid问题；3.单点退出时有时子系统未能正常退出；4.有些请求路径不需要单点登录过滤器拦截；5.不同应用服务实现可能要求SSO客户端做适应性改造。我们具体分析一下，并提出解决方法。

1.超时问题

我们提供的CAS开源单点登录SSO组件，它部署节点主要有2个：SSO服务器(部署内容为一个web应用)、应用系统客户端(部署内容为cas客户端casclient.jar包和相关配置文件)。因此我们根据SSO机制分析一下什么情况下会出现超时。多个应用系统进行SSO集成后，SSO单点登录过程中，登录成功后，应用系统客户端(以下用浏览器客户端为例)的session会保存认证后的用户上下文，SSO服务器会生成一个用户凭证票据(TGT)并缓存起来，浏览器客户端会保存TGC(浏览器cookie中存储的TGT)，TGT是作为发放SSO访问服务的票据(ST)的一个凭证票据，发放ST票据后才能正常访问。而浏览器客户端的session会超时(如一般web应用客户端可以设置session的timeout值为30分钟或更长)，超时后会让session失效，清空用户上下文，TGC因为仍然是保存在浏览器cookie中，只有关闭浏览器才会清除。SSO服务器端的超时主要是TGT、ST超时，我们一般会设置超时值TGT为2小时，ST为5分钟。关于ST票据使用，一般在首次SSO访问服务时携带着该票据参数，验证票据后能正常访问后，SSO服务器就将此ST销毁失效了；关于TGT票据的使用，一般是正常访问时一直保持为超时时间(2小时)，除非做单点退出会销毁TGT。

基于以上分析，我们可以得出结论，SSO的超时主要涉及2个要素：浏览器的session超时值、TGT的超时值。一般系统设置TGT的超时值>浏览器的session超时值，那么可能有2种超时情况：1.TGT超时(浏览器session超时值小，自然也超时)；2.浏览器session超时，TGT不超时。

第一种“1.TGT超时”，这个处理很简单，用户的有效凭证票据都失效了，自然要重新取得有效凭证票据TGT，需要做的就是重新跳转到登录页面重新登录。

第二种”2.浏览器session超时，TGT不超时“，这时SSO服务器的TGT票据，以及浏览器客户端的TGC(cookie中的TGT)仍然有效。浏览器客户端再次SSO访问时就可以携带TGC(与服务器的TGT对应)，向SSO服务器重新发送取得票据ST请求，取得票据ST后，携带着有效ST票据可以正常访问应用系统了。这个过程是浏览器客户端与SSO服务器的一个通讯交互，用户可能感觉不到，不会出现中断，好像能连续访问，这是为了给用户一个友好的访问体验。明白这个机制，就知道实际上是SSO机制在后台起作用了。

2.jsessionid问题

jsessionid是java客户端与应用服务器维持session的一个标识，其他语言客户端(如php)有其他标识关键字，具体是什么还不太了解。jsessionid一般存在于浏览器cookie中的(这个一般java客户端连接到应用服务器会自动执行的)，一般情况下不会出现在url中，服务器会从客户端的cookie中取出来，但是如果浏览器禁用了cookie的话，就要重写url了，显式的将jsessionid重写到Url中，方便服务器来通过这个找到session的id。CAS开源单点登录SSO组件就提供了这个机制。我研究了CAS源码，基本明白了jsessionid的处理机制。大致原理如下：用户访问业务系统，SSO客户端拦截，重定向到SSO服务器认证时，就将请求路径uri中写入";jsessionid=具体的session值"，SSO服务器可以分辨出这个标识值与其他客户端请求不同，进行认证处理，返回的响应给客户端cookie同时也设置了jsessionid的值，之所以在uri和cookie中都设置了jsessionid，是为了双重保障能设置jsessionid值。最后单点登录成功后，返回业务系统访问地址也带有jsessionid参数，这个在uri地址中看起来很别扭。

提供2种解决方法，如下：

1) 可以在登录页面地址的请求地址参数中加入参数”&