开发SSO单点登陆须要注意的问题

时间 2020-07-14

原文原文链接

1、单点登陆系统开发须要注意的问题

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进行了扩展，思路也很简单，主要是将显示默认登陆页面的调用，变成了远程调用业务子系统的页面地址，这个地址能够做为配置参数来配置。

2、关于用户注册，须要注意的几个问题
    1.避免用户密码泄露
    （1）在前端对密码MD5加密后再传给后台。
    （2）后端：登陆时用户信息存入redis缓存时，密码禁止存储，更要禁止传到前端页面。
    2.用户注册信息的校验
    （1）前端校验
    （2）后端校验；前端

3、上线后可能遇到的问题
1.可能遇到Cookie没法写入的问题java

缘由：Nginx向Tomcat转发请求时，丢失了域名。nginx

经过request对象获取请求的域名时，没有获取到真实的请求域名，致使cookie写入失败。解决：web

分析：用户--->Nginx-->Tomcatajax

在nginx作请求转发时将请求的域名丢失了，致使在tomcat中没法获取真实的请求域名。redis

有须要交流的小伙伴能够点击这里加本人QQ：luke
chrome