一、单点登录系统开发需要注意的问题

1.单点登录系统需要支持jsonp请求？

单点登录系统主要是向其他系统提供用户身份验证服务，因此需要提供对外接口，而外部系统通过接口访问时，必然涉及跨域问题，因此需要单点登录系统支持jsonp消息转换，即能正确处理跨域请求。否则，请求接收到的数据解析失败，chrome debug中提示“Uncaught SyntaxError: Unexpected token <”。

2.超时问题

我们提供的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机制在后台起作用了。

3.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地址中看起来很别扭。

解决方法，如下：
（1） 可以在登录页面地址的请求地址参数中加入参数”&method=POST“(记住这里要求POST大写)，这样就可以在最后返回的访问uri中不显示jsessionid。

4.单点退出时有时子系统未能正常退出

我们知道正常情况下，以用户A单点登录系统，正常访问各子系统，然后执行单点退出时，退出成功后一般跳转回到登录页面要求重新登录，这时各已登录的子系统session被销毁，再次以另一个用户B登录进入后，各子系统显示的应当是用户B的数据信息。可是有时却发现有些子系统仍然显示的是用户A的数据信息，这属于偶发现象。现在分析一下产生这种情况可能的原因，找出解决办法。

5.有些请求路径不需要单点登录过滤器拦截
业务系统web应用在使用单点登录组件时，有些请求路径不需要单点登录过滤器拦截，比如公共开放的路径，不需要认证都可以自由访问的路径，单点登录过滤器配置的映射路径一般以通配符匹配路径，但要把这些路径单独提取出来，让过滤器不拦截做单点登录处理，就需要对原有过滤器进行扩展改造，才能实现这个功能。

6.不同应用服务实现要求SSO客户端做适应性改造

不同应用服务，对请求的处理方式不同，SSO客户端常规方法不能处理的需要进行适应性改造。我们先看一下SSO客户端常规方法处理请求，web应用中定义一个过滤器casfilter，并配置对安全资源拦截，首次登录系统、或者访问超时时，安全资源的请求被过滤器casfilter拦截，将安全资源路径包装为service参数，并重定向（http状态为302）到SSO服务器地址进行认证，输入凭证信息(用户名、密码等)，SSO服务器经过认证、验证票据机制处理，认证成功后；

登录通过后继续访问安全资源，再次访问安全资源时，过滤器casfilter拦截，根据用户上下文判断用户已经登录，就不再拦截安全资源，直接正常访问安全资源。而有些应用中使用其他方式处理请求，按上述常规方法不好处理，下面举实例来看看解决方案。

6.1.Ajax客户端

公司有一个应用系统使用Ajax客户端来处理请求并取得响应，在访问超时时，Ajax客户端请求由于使用异步处理技术（只局部刷新页面），不能将请求继续302重定向到SSO服务器重新认证处理，不能继续访问安全资源，界面响应处于一直延迟状态，很不友好。我们针对此应用进行适应性改造。改造要点如下：

我们约定应用系统的一个Ajax请求的标记（如ajaxRequestFlag=ajaxRequest），在安全资源ajax调用请求时携带此请求参数，还约定一个超时请求的响应状态值（如555），SSO客户端的过滤器casfilter的相应类程序对此约定进行了相应的改造。

应用系统的安全资源页面中引入文件（HttpStatusSSO.js）SSO对Axax请求的http状态的处理，其中有超时时的状态处理、判断是否登录、验证票据等的处理，都是通过ajax请求方式来处理的，其中依赖一个验证票据的资源ticketValidate.jsp。

经过上述改造后，应用系统的安全资源发送携带ajax请求标记的请求，在超时请求时，SSO客户端返回约定响应码(555)，HttpStatusSSO.js文件判断处理后转发给相应的登录页面重新认证。单点登录的访问也能够正常的实现功能。这样只扩展了SSO客户端组件的实现，向下版本兼容，保证了SSO组件的统一完整性。

6.2.多域认证

有时我们遇到，不同子系统的认证实现的数据源可能来自一个用户数据库。我公司就是这种情况，采用Saas模式运营的软件，认证的用户来源于不同的租户或者域，基于这样的情况，我们对SSO进行了扩展，主要提供了认证接口，认证实现上，可以在认证时动态取得租户对应的数据源，对用户进行认证处理。

6.3.SSO集中认证登录页面需要在业务子系统中定制

SSO集中认证的登录页面默认是放在SSO服务器端的，样式也很不好看，用户需要把登录页面放在业务子系统中自行定制，我们对SSO进行了扩展，思路也很简单，主要是将显示默认登录页面的调用，变成了远程调用业务子系统的页面地址，这个地址可以作为配置参数来配置。

二、关于用户注册，需要注意的几个问题

1.避免用户密码泄露
（1） 在前端对密码MD5加密后再传给后台。
（2）后端：登录时用户信息存入redis缓存时，密码禁止存储，更要禁止传到前端页面。

2.用户注册信息的校验
（1）前端校验
（2）后端校验；

三、上线后可能遇到的问题

1.可能遇到Cookie无法写入的问题
原因：Nginx向Tomcat转发请求时，丢失了域名。

通过request对象获取请求的域名时，没有获取到真实的请求域名，导致cookie写入失败。 解决：
分析：用户—>Nginx–>Tomcat
在nginx做请求转发时将请求的域名丢失了，导致在tomcat中无法获取真实的请求域名。