一种基于CAS统一认证服务中间件的SSO认证方法与流程

本发明属于网络信息技术领域，具体涉及一种基于CAS统一认证服务中间件的SSO认证方法。

背景技术：

CAS(Central Authentication Service，中央认证服务)是主流的SSO(Single Sign On，单点登录)开源解决方案，主要实现基于B/S(Browser/Server，浏览器/服务器)结构的应用系统用户SSO，交互协议主要基于http及安全的https。

传统的SSO技术只能支撑用户在同一个部署单位内的业务系统SSO，无法实现跨部署单位(域)的SSO。原生CAS技术提供的SSO认证机制如下：

1.由客户端和服务端两部分组成；在应用时，客户端被集成到业务系统运行时环境中(此处的业务系统是指需要集成SSO认证的系统)，服务端则独立部署。

2.用户访问业务系统时，内置的CAS客户端组件会拦截用户请求，并检查用户会话有效性；如果会话有效，则允许访问；如果会话无效，则将用户请求转发至服务端，进入下一步。

3.CAS服务端检测用户客户端是否存储了TGT(Ticket Grangting Ticket)，如果有则说明已经登陆过，则自动为客户端生成用于访问业务系统使用的ST(Service Ticket)，并将请求再次转发到业务系统端。业务系统根据第2步的描述再次进行ST和会话校验。但如果检测到客户端没有TGT，服务端将会展现登陆界面，要求用户登陆，并进入下一步。

4.用户输入登陆认证信息并提交，CAS服务器对登陆信息进行校验，校验通过则为客户端生成TGT，同时产生ST，然后将请求转发到业务系统；此时用户将成功进入系统，并建立有效的Session。

基于上述机制的CAS架构如图1所示，这种CAS架构在整个软件界有C/S(Client/Server，客户机/服务器)转向B/S架构的过程中，发挥了非常重要的作用。用户只需要注册一次，便可登录其他子系统，借助于浏览器的Cookie机制和http的重定向功能，也能一定程度上完成用户认证的保活。

但是，在2010年之后，移动互联网发展迅猛，各个公司都开始开发自己的原生应用，Android、iOS双管齐下。但是原生应用存在着一些问题，就是开发周期长，更新难度大等问题，于是基于Webview的Hybrid技术应运而生。

这种嵌入Webview的方式很好的解决了上述问题，但也带来了新的挑战。那就是原来的CAS登录系统在这种Hybrid应用中，并不能很好地施展和复用。比如我们在应用的Native部分使用原生HttpClient通过CAS登录了Client1，而应用中某个Webview指向的是Client2，由于Webview并没有认证通过的Cookie，就会重定向到CAS登录页面，这样的用户体验就会非常的差，但是又不能省去。那么就希望有一种技术，可以让我们在重用CAS系统的认证机制时，又能保有良好的用户体验。

技术实现要素：

鉴于上述，本发明提供了一种基于CAS统一认证服务中间件的SSO认证方法，可以方便在一些C/S架构中实现一次登录随意调用的效果，由中间件维护客户端与各个接入CAS的服务的会话，实现了自动登录，会话维持，过期重试等功能，帮助传统系统轻松开发App等类型客户端。

一种基于CAS统一认证服务中间件的SSO认证方法，在CAS系统中布置UAS(统一认证服务)中间件，具体实现如下：

(1)当用户端向CAS服务器提交登录请求时，由所述UAS中间件负责拦截该请求并进行转发，同时存储CAS服务器返回的TGT；

(2)当用户端访问CAS客户端的服务接口时，同样由UAS中间件负责拦截其http请求，通过调用会话Cookie访问服务接口以获取响应结果并转发给用户端；其中若用户端为首次访问，UAS中间件则利用所述TGT从CAS服务器换取到ST，进而利用ST从对应的CAS客户端换取得到所述的会话Cookie。

所述步骤(1)的具体实现过程为：用户端向CAS服务器提交登录请求(用户名、密码、验证码等)，UAS中间件拦截到该请求后先建立与用户端的唯一会话，然后将登录请求转发至CAS服务器；若CAS服务器验证通过，则UAS中间件获取CAS服务器返回的TGT和会话Cookie，并将TGT、会话Cookie以及当前登录用户的用户名存储于用户端在UAS中间件的Session中，最后向用户端返回其与UAS中间件的会话Cookie；若CAS服务器验证失败，则UAS中间件直接向用户端返回验证失败信息(密码错误等)。

所述步骤(2)的具体实现过程为：当用户端访问CAS客户端的服务接口，UAS中间件拦截到对应的http请求后先从该用户端在UAS中间件的Session中查找是否存有对应CAS客户端的会话Cookie：

若有，则UAS中间件调用该会话Cookie并将其加入至所述http请求的请求头中，然后执行请求访问服务接口，并将服务接口所返回的响应结果转发给用户端；

若没有，则UAS中间件从Session取出该用户的TGT并去CAS服务端换取对应CAS客户端的ST，进而携带该ST访问对应的CAS客户端，CAS客户端则上访CAS服务端以验证该ST是否合法，若合法则会给予UAS中间件一个会话Cookie，UAS中间件先将该会话Cookie存储于Session中，然后调用该会话Cookie并将其加入至所述http请求的请求头中，进而执行请求访问服务接口，并将服务接口所返回的响应结果转发给用户端。

所述步骤(2)中若UAS中间件调用会话Cookie访问服务接口失败，则表明该会话Cookie已失效，此时UAS中间件并不直接把代理访问错误的信息返回给用户端，而是从Session取出该用户的TGT并去CAS服务端换取对应CAS客户端的ST，进而携带该ST访问对应的CAS客户端，以获取新的会话Cookie对服务接口进行访问。事实上，这样就完成了在B/S架构中，在CAS客户端会话过期但CAS服务端会话未过期时，基于重定向的方式完成重新登录的工作。

所述步骤(2)中若UAS中间件持有TGT无法从CAS服务器换取到ST，则表明该TGT已过期，此时UAS中间件直接告知用户端“会话过期，需要重新登录”，则用户端根据步骤(1)重新进行登录。

优选地，所述的UAS中间件设置有定时保活程序，即用户端首次向CAS服务器提交登录请求时，UAS中间件拦截到该请求后保存该用户的用户名和密码，并定期访问CAS服务器获取TGT，以保证该用户的TGT是最新的；同时若UAS中间件持有TGT无法从CAS服务器换取到ST，此时UAS中间件并不直接告知用户端“会话过期，需要重新登录”，而是利用该用户的用户名和密码访问CAS服务器获取新的TGT，进而利用新的TGT从CAS服务器换取ST。当然这种情况受限于当前使用的CAS服务端有没有使用验证码等因素，因此只是可选的。

优选地，所述UAS中间件布置于用户端，其通过Interceptor拦截器以及Redis、Sqlite或Realm的存储方案来实现。

为提高Session的效率，优选地，所述UAS中间件采用Redis高速缓存方案作为Session的存储实现形式。

用户在首次登陆时，由中间件负责拦截并存储请求返回的TGT，当用户在客户端端需要调用其他系统接口时，由中间件负责判断是否已经登录过此系统，若未登录，则先用之前的TGT去CAS换取对应系统的Ticket，进而完成对该系统认证工作，之后再调用该接口。本发明使得原先基于浏览器重定向机制的CAS认证方式，可以很方便的在客户端上使用，方便在一些C/S架构中实现一次登录随意调用的效果，保证了良好的用户体验，实现了自动登录，会话维持，过期重试等功能，帮助传统系统轻松开发App等类型客户端。

附图说明

图1为基于传统SSO认证机制的CAS系统架构示意图。

图2为本发明基于统一认证服务中间件的CAS系统架构示意图。

图3为本发明UAS中间件的实施架构示意图。

图4为UAS中间件布置于用户端的实施架构示意图。

具体实施方式

为了更为具体地描述本发明，下面结合附图及具体实施方式对本发明的技术方案进行详细说明。

如图2所示，本发明提供了一个对接使用CAS作为SSO方式系统的认证中间件，使得原先基于浏览器重定向机制的CAS认证方式，可以很方便的在用户端上使用，其具体实现包括如下过程：

1.用户端提交登录信息(用户名，密码，验证码等)到CAS服务器时，由UAS中间件负责拦截此次请求。

2.若认证通过，则UAS中间件存储返回的当前登录用户的有效TGT和用户名；若验证失败，则告知用户对应的验证失败信息(密码错误等)。

3.当用户端访问CAS客户端的接口时，同样由UAS中间件拦截，若是第一次调用此CAS客户端，则中间件用步骤2中存储的TGT去CAS服务端换取对应CAS客户端的ST。

4.UAS中间件携带步骤3中的ST访问用户希望访问的CAS客户端；CAS客户端去CAS服务端验证此ST是否合法，若合法，将会给予UAS中间件一个标记此次会话的Cookie，这样UAS中间件就拥有了用户名、TGT、会话Cookie这三个信息。

5.此时UAS中间件在用步骤4中的Cookie去访问步骤3中用户端想要访问的CAS客户端接口，获取内容，并返回给用户端，完成此次接口调用。

6.当用户端再次调用上述步骤中的同一CAS客户端时，因为中间件已经持有对应的会话Cookie，所以不必再经过步骤3、4，直接携带Cookie调用，然后将结果代理返回给用户端即可；若调用的CAS客户端之前没有调用过，则同样按照步骤3、4、5完成对此CAS客户端的调用。

7.若在UAS拥有目标CAS客户端的会话Cookie时，调用其接口出现失败，返回401Unauthorized或者403Forbidden等错误，说明持有的Cookie失效，此时UAS中间件不是直接将这个错误代理返回给用户端，而是重复步骤3、4、5，用TGT再次换取ST和对应CAS客户端会话Cookie的工作。事实上，这样就完成了在B/S架构中，在CAS客户端会话过期但CAS服务端会话未过期时，基于重定向的方式完成重新登录的工作。

8.当然在步骤3中，也有可能出现拿持有的TGT无法换取对应ST的情况，如持有的TGT过期的情况，此时就需要告知用户端“会话过期，需要重新登录”，这样又回到了步骤1的情况。

9.当用户端有用户长期保持登录会话的需要时，为了避免步骤8中的情况，可以在UAS中间件中设置一个定时任务，定期访问一次CAS服务端，以完成此当前持有TGT的保活工作。若需要更严格和可用性更高的保活服务，可在步骤2中除存储用户名和TGT之外，也存储下用户名对应的密码，在步骤8时可不用告知用户重新登录，而是由UAS中间件自动重新登录CAS服务端，获取新的TGT，当然这种情况受限于当前使用的CAS服务端有没有使用验证码等因素，因此只是可选的。

实施例1：

本实施方式通过架设新的服务来实现这种中间件，这种方案下用户端事实上永远访问的是中间件，由中间件基于http-proxy代理转发请求，并维持与用户端之间的会话；具体实施步骤如下：

(1)用户端将无论是访问CAS服务端的域名还是CAS客户端的域名的DNS指向都改为UAS代理中间件的IP。如CAS服务端的域名为cas.domain.com，提供商城服务的CAS客户端域名为mall.domain.com，提供论坛服务的CAS客户端域名为bbs.domain.com；而我们UAS中间件的地址uas.domain.com的DNS指向为192.168.1.100，那么我们需在用户端的DNS新增三条记录如下：

cas.domain.com 192.168.1.100

mall.domain.com 192.168.1.100

bbs.domain.com 192.168.1.100

当各个CAS客户端的提供的接口路径没有冲突的情况下，也可以不用配置DNS直接使用IP访问。

(2)用户在用户端提交登录信息至CAS服务端时，事实上被UAS中间件拦截。UAS先建立与用户端的唯一会话后，将登录请求转发至CAS服务端，获取TGT，并将TGT和CAS服务端写回的会话Cookie存储于用户端在UAS中间件的Session中，然后将用户端与UAS中间件的会话Cookie返回给用户端。

(3)当用户端请求各个CAS客户端的服务接口时，同样由UAS中间件拦截转发，当发现Session中没有存储对应CAS客户端的Cookie时，则按照上述步骤3拿Session中的TGT去CAS服务端换取ST，然后按照上述步骤4换取对应CAS客户端的会话Cookie，同样存储在当前Session中。接下来就和当发现有对应CAS客户端的Cookie时的过程一致，取出对应CAS客户端的Cookie，并加入将要转发至对应CAS客户端的http请求的请求头中，然后执行请求，并转发请求返回结果给用户端。

(4)每个CAS客户端都访问过一遍之后，用户端在UAS中间件上的Session中大致存储如下信息：

user：xxx

cas-tgt：xxx

cas-cookie:xxx

mall-cookie:xxx

bbs-cookie：xxx

…

为提高Session的效率，可以使用Redis等高速缓存方案来作为整个Session的存储介质。

这种实施方案的架构大致如图3所示，其中CAS-S代表CAS服务端，CAS-Cn代表多个CAS客户端；这种方案的好处是可以在保持原有CAS服务端和CAS客户端不做任何更改的情况下，实现最小化用户端编程，减轻用户端开发的开发工作；但这种情况需要注意UAS中间件高可用的问题，业务量较大时，可以考虑部署多台。

实施例2：

本实施方式通过在用户端上实现这种中间件，这种方案下需要借助Android/iOS/UWP等客户端平台(以下统称App)对应的开发技术来实现这样一个拦截相关网络请求并存储相关数据的中间件，具体包括以下步骤：

(1)用户在客户端登录界面提交登录信息时，使用Interceptor拦截请求，并将需要存储的用户名、TGT、会话Cookie等信息选择合适的存储方案进行存储(如Sqlite、Realm等)进行存储。

(2)按上述步骤拦截用户端对对应CAS客户端的请求，在未获取对应CAS客户端会话Cookie时，使用本地存储的TGT去换取ST，进而换取对应CAS客户端需要的Cookie，完成整个访问过程；这种方案的架构大致如图4所示。

正是有了实施例1可能存在高可用的问题，将UAS中间件部署在用户端，可以完美解决这一问题。需要注意的是，这种方案需要针对iOS/Android/UWP等多个平台分别编程，可能会带来一些开发工作量。

上述对实施例的描述是为便于本技术领域的普通技术人员能理解和应用本发明。熟悉本领域技术的人员显然可以容易地对上述实施例做出各种修改，并把在此说明的一般原理应用到其他实施例中而不必经过创造性的劳动。因此，本发明不限于上述实施例，本领域技术人员根据本发明的揭示，对于本发明做出的改进和修改都应该在本发明的保护范围之内。