李晓永，王福喜
（华北计算技术研究所，北京100083）
摘要：针对传统基于票据的Web应用单点登录系统在组合应用访问上的不足以及基于证书的Web应用单点登录系统存在的效率问题，提出一种改进的基于票据的Web应用单点登录系统。该系统实现了不同域名的Web应用单点登录，引入代理票据实现了组合应用访问时的单点登录，采用票据进行身份认证，避免了数字签名以及多重数字签名带来的认证效率问题。
教育期刊网 http://www.jyqkw.com
关键词 ：单点登录；票据；代理票据；TGT；Web应用
中图分类号：TN915?34；TP393 文献标识码：A 文章编号：1004?373X（2015）13?0085?05
收稿日期：2014?12?21
0 引言
随着网络技术和信息技术的不断发展，用户对于信息和服务的需求不断增加，各种应用服务不断普及，用户使用的应用系统越来越多。用户需要牢记大量应用系统的登录信息，给用户带来了很大的麻烦，为了减少麻烦，用户一般采用相同而且方便记忆的口令，这就带来了极大的安全隐患，同时加上各应用系统的认证系统存在各种差异，严重阻碍了系统间的信息交互，单点登录正是在这一背景下产生的。单点登录的目的是“一次登录，自由切换”，即用户可以在只进行一次主动的身份认证前提下，就可以自由访问多个授权内的应用资源。
在Web 应用环境下，用户通过访问Web 应用获取资源，有时，为了业务功能以及用户体验的需要，某些Web应用之间需要相互访问来获取资源，将后者定义为组合应用访问。传统的基于票据的Web应用单点登录系统在用户登录成功后为其生成一张票据，结合Web应用系统特有的Cookie技术实现了用户访问Web应用时的单点登录，但由于Cookie的限制，该系统要求Web应用必须具备相同的域名，部署起来不太方便，同时该系统并未给出组合应用访问时单点登录的解决方法。
基于证书的单点登录系统通过引入多重签名技术给出了组合应用访问时单点登录的解决方法，但是缺点也十分明显，需要对证书链上的每个签名进行验证，认证效率太低。
针对上述问题，本文给出一种改进的基于票据的Web应用单点登录系统，解决了Cookie对于Web应用域名的限制，同时引入代理票据解决了组合应用访问时的单点登录，避免了多重数字签名带来的效率问题。
1 传统单点登录方案
1.1 基于票据的单点登录
传统的基于票据的单点登录在用户的登录信息认证通过后，认证服务器为用户生成一张票据，票据由随机的字符串组成，以键值对的形式附在URL后面，用户携带此票据访问Web应用资源，Web应用验证票据合法后，返回用户访问的资源，同时会附带一个Cookie，Cookie中包含了用户的身份信息，之后用户访问同域名的其他Web应用时会自动携带该Cookie，Web应用通过该Cookie了解到用户已经登录，直接返回访问的资源，无需再次对用户进行身份认证，实现了单点登录。由于Cookie本身对域名的限制，单点登录范围内的Web应用必须含有相同域名，同时该传统方案未给出Web 应用之间即组合应用访问的单点登录流程。
1.2 基于证书的单点登录
基于证书的单点登录主要由CA（证书授权）、Web应用服务器和用户三部分组成。通过CA签发证书实现用户访问服务器的单点登录，认证过程与上述方案类型。在面对组合应用访问需求时，用户将证书作为自己的身份凭证委托给Web 应用，组合访问链上Web 应用依次给证书签名，最后一个Web 应用需要对证书链上的所有签名逐个验证，验证通过后，直接返回访问的资源，无需再次对用户进行身份认证，实现了组合应用访问的单点登录。对于证书的签名和验签，尤其对多重签名的验签需要花费大量时间，因此该方案存在认证效率问题。
1.3 改进的单点登录方案
针对以上传统单点登录方案存在的不足，改进方案的主要设计思想如下：
（1）更改基于票据的单点登录流程，实现不同域名的Web应用单点登录；
（2） 引入代理票据，实现Web 应用之间的身份认证；
（3）设计基于代理票据的单点登录流程，实现组合应用访问时的Web应用单点登录。
2 单点登录系统设计
2.1 单点登录系统总体模型
基于以上对于单点登录方案的分析，设计基于票据的Web应用单点登录系统模型如图1所示。
单点登录系统主要包括两类安全实体：
（1）单点登录代理组件：以Web应用插件的形式存在，部署在Web 应用端，截获用户访问Web 应用请求，实现对请求中身份信息的检查完成身份认证，实现用户访问Web应用时的单点登录。
（2）单点登录服务器：以独立运行系统的形式存在，对用户及Web 应用的身份信息以及票据信息进行管理，能够基于票据对用户及Web应用进行身份认证。
单点登录系统的总体流程如下：首先用户访问Web应用，部署在Web 应用端的单点登录代理组件截获该访问请求，检查到请求中不含票据，然后将请求重定向至单点登录服务器，单点登录服务器的身份认证模块会提示用户进行登录，登录成功后，单点登录服务器的票据管理模块会为该用户生成一个票据，之后用户携带票据重新访问Web 应用，部署在Web 应用的单点登录代理组件取出票据并将票据提交给单点登录服务器获取身份认证结果，根据结果决定是否提供访问资源。
2.2 单点登录流程
用户在单点登录服务器端完成用户信息注册后访问已部署单点登录代理组件的Web应用。图2描述了本次访问过程中用户、Web应用服务器以及单点登录认证服务器之间的身份认证流程。
（1）用户初始访问应用服务器A；
（2）部署在应用服务器A 的单点登录代理截获访问请求，判定请求中是否含有Cookie 和身份登录票据（由身份认证服务器生成的身份断言索引值，之后认证服务器可以基于该索引值惟一索引到用户的身份断言），若不含有，单点登录代理将地址重定向至认证服务器；
（3）认证服务器查询用户未登录（请求中没有认证服务器的Cookie），向用户返回一个用户登录页面；（4）用户在登录页面上输入身份信息（用户名口令或用户证书信息）；
（5）认证服务器验证用户的身份信息，认证通过后，生成用户的身份断言以及与之关联的断言索引值（即身份登录票据ST）存放在认证服务器数据库中，将断言索引值附加到用户的Http请求中，地址重定向至应用服务器A，同时认证服务器生成一个Cookie 返回给用户；
（6）应用服务器A的单点登录代理截获访问请求，判定请求中是否含有票据，若含有，则执行第（7）步；
（7）应用服务器A 依据解析出的票据生成用户断言请求，请求发给认证服务器；
（8）认证服务器验证身份登录票据的有效性，验证通过后，依据票据查询本地数据库从而获取用户断言返回给应用服务器A，同时废弃该票据；
（9）应用服务器A的单点登录代理验证身份断言，验证通过后，执行访问控制流程，向用户返回请求的访问资源，同时附带一个Cookie（存储当前请求的sessionID，之后用户再次访问应用服务器Ａ，可以自动携带这个Cookie，应用服务器A通过Cookie中的sessionID可以得到session获取用户身份，不用再次认证）。
认证服务器返回给客户端的Cookie 就类似于Ker?beros 的TGT（票据授权票据），之后客户端想要访问其他应用，就可以通过该Cookie来获取访问应用的票据而不用再次登录。Cookie 中的内容包括{UserID，UserIP，LoginTime}，其中UserID标识了当前用户的名称，UserIP标识了用户的客户端地址，防止在其他客户机上被非法使用，LoginTime标识了用户的登录时间，同时还可以设定Cookie的有效期，过了有效期，Cookie就会自动失效，用户若访问应用服务就必须重新登录，一般可以将有效期设为8 h（一个工作日）。在Kerberos 协议中，由于TGT可以重复使用，因此对于其安全性要求非常高，在本方案中，为防止该Cookie被非法盗用，Cookie的发放通道采用了基于SSL的安全通道，同时Cookie中的内容也进行了加密，认证服务器提取Cookie信息后需要首先解密，再加上对Cookie设置的有效期，保证了其在传输和使用上的安全。
图3描述了用户访问Web应用服务器A后接着访问部署了单点登录代理组件的Web应用服务器B的认证流程，用户无需登录即可直接访问Web应用服务器B。
（1）用户访问应用服务器A 之后，访问应用服务器B；
（2）部署在应用服务器B 的单点登录代理截获访问请求，判定请求中是否含有Cookie 和票据ST，若没有，将地址重定向至认证服务器；
（3）用户客户端发现本地存有认证服务器的Cookie，http请求携带此Cookie发送至认证服务器；
（4）认证服务器提取Cookie并获得用户登录信息，验证合法性，认证服务器已有用户断言，不再向用户返回登录页面，直接为用户生成新的身份登录票据，后续流程与用户初次访问应用服务器A一样，至此，用户无需再次登录就可以直接访问应用服务器B，实现了单点登录。
2.3 组合应用访问单点登录流程
上述的单点登录流程无法解决另外一种情况，即用户访问应用服务器A，应用服务器A需要依赖应用服务器B来完成这次请求，这种情况定义为组合应用访问。在组合应用访问中，应用服务器B需要完成对用户的身份认证，一种可行的解决方案是应用服务器B将请求重定向至认证服务器，与访问应用服务器A的认证流程一样，通过TGT获取ST，再通过ST认证用户的身份，但这种方式会带来一个新的问题就是过多的重定向，重定向会导致用户浏览器地址栏里的地址跳转，太多的跳转就会带来极差的用户体验，这种认证方案显然不太合适。在此采用委托代理的方法，即应用服务器A代理用户去完成身份认证的工作，并在认证过程中引入代理票据。用户访问应用服务器A，按照图1所示的身份认证流程获得身份票据ST，然后携带ST访问应用服务器A，之后的身份认证流程如图4所示。
（1）应用服务器A 向认证服务器提交验证票据请求，同时会在请求中附带一个TGTurl，该url惟一地且安全地标识应用服务器A的身份。
（2）认证服务器通过ST查询到用户的身份信息断言，接着认证服务器会通过TGTurl来验证应用服务器A的身份，这个url必须是https的，认证服务器访问该url获取应用服务器A的身份信息，同时验证其SSL证书。
（3）如果验证失败，把身份信息断言作为响应信息返回，响应信息中不包含TGT，本次身份认证流程结束；
如果验证通过，进行步骤（4）。
（4）认证服务器生成一个TGTID 和身份信息断言一起作为响应信息返回（考虑到TGT的重要性，在其传递过程中不能被非法用户窃取，因此这里没有直接返回TGT）；同时，认证服务器会再次访问TGTurl，并将TGTID和TGT传递给应用服务器A，由于TGTurl是https形式，保证了TGT的传递通道是安全的。
（5）应用服务器A 通过TGTID 查到TGT，并将TGT保存在本地。
之所以引入TGTurl而不是直接发放TGT是为了确保应用服务器A的身份是可信的，同时由于TGT的重要性，其发放的通道也是基于SSL 的安全通道，同时TGT本身也是加密过的，只有认证服务器自身可以解密。有了TGT应用服务器就可以使用TGT去请求票据，这里把委托代理拿到的票据称为代理票据PT（Proxy Ticket），区别于上述流程中的ST，应用服务器A 在访问应用服务器B之前，需要先使用TGT去向认证服务器获取PT，单点登录流程如图5所示。
（1）应用服务器A携带TGT访问认证服务器，请求PT；
（2）TGT验证通过，认证服务器返回PT；
（3）应用服务器A携带PT访问应用服务器B；
（4）应用服务器B提交PT给认证服务器，请求认证用户身份；
（5）PT 验证通过，返回用户身份断言给应用服务器B。
Web应用在认证服务器注册时，会为其维护一张应用访问权限表，即该Web应用可以访问哪些应用，当然前提是被访问者允许其访问自己的资源。之后在收到PT验证请求后，单点登录服务器会首先验证其合法性，之后会通过PT 找到其关联的TGT，然后会访问该TGT的持有者应用服务器A的访问权限表，判断其是否有权限访问应用服务器B，如果没有，直接拒绝该请求，防止Web应用被越权访问。
3 票据安全性分析
在上述单点登录流程中，用户最终通过票据访问服务，而票据的发放又依赖于TGT（票据授权票据），因此TGT和票据涉及到整个单点登录系统的安全。本文基于SSL通道分发TGT和票据，防止在传输过程中被人窃取，同时对内容进行加密，密文只由单点登录认证中心才能解开。TGT和票据都设置了有效期，超过有效期将自动失效。同时票据被设定为只能使用一次，用户携带票据访问服务后，该票据将自动失效，防止重放攻击。同时产生票据的随机数必须足够随机，防止规则过于明显被人为猜出。
4 单点登录系统实现
单点登录系统的实现主要有两部分：单点登录代理组件和单点登录服务器。本文给出基于JAVA 开发的Web应用单点登录系统实现方案。单点登录代理组件部署在Web 应用端，负责拦截对本地Web 应用的受保护资源的访问请求，对请求方进行身份认证，并将认证请求重定向至单点登录服务器；单点登录服务器单独部署，负责完成对用户的认证工作。其中身份认证代理组件以jar包的形式存在，如果某个Web应用要使用该单点登录系统，只需将身份认证代理组件的jar包放置在本应用的外部依赖库内，并在自己的Web.xml配置文件内添加如下所示的配置代码，即可成功部署单点登录系统，避免“硬编码”形式给系统部署带来的不便。
（1）<filter>
（2）<filter?name>HttpProxy</filter?name>
（3）<filter?class>com.nci.filter.LoginFilter</filter?class>
（4）<init?param>
（5）<param?name>IDPLoginURL</param?name>
（6）<param?value>https：//192.168.31.111：8080/IAServer/Log?inServer</param?value>
（7）</init?param>
（8）<init?param>
（9）<param?name>IDPServiceURL</param?name>
（10）<param?value>https：//192.168.31.111：8080/IAServer/ser?vices</param?value>
（11）</init?param>
（12）</filter>
（13）<filter?mapping>
（14）<filter?name>HttpProxy</filter?name>
（15）<url?pattern>/*</url?pattern>
（16）</filter?mapping>
单点登录代理组件采用了servlet的filter技术，代码中的第（6）行配置了单点登录服务器的登录请求处理地址，初次进行身份认证的请求被重定向至该地址；第（10）行配置了单点登录服务器的地址，单点登录代理组件拿到请求访问者的票据后，需要通过该地址与单点登录服务器进行通信来获取用户的身份信息；第（15）行配置了所要拦截的URL 形式（图中配置的URL 形式为拦截所有Web 请求）。单点登录代理组件的配置方式避免了与业务服务器的功能耦合，可以在无需对Web应用修改的情况下部署并对Web 应用实施安全保护，如果需要更换单点登录服务器，只需更改配置代码中的单点登录服务器的地址即可。
单点登录服务器分为用户登录、票据（ST）管理、代理票据（PT）管理和断言管理四个模块。其中用户登录模块负责验证用户的登录信息；票据管理模块负责验证和管理用户的访问票据；代理票据模块负责验证和管理用户的票据授权票据（TGT）和代理票据；断言管理模块负责管理用户的身份信息断言。
5 实验结果及分析
5.1 实验环境
为了验证单点登录系统的正确性和有效性，本文针对Web应用环境进行了测试部署，其测试场景如图6所示。测试环境中共部署一台单点登录服务器、一台用户终端和三台Web应用服务器，它们之间通过网络连接，三台Web应用服务器都部署了单点登录代理组件。其中Web应用A与Web应用B之间的调用关系为Web应用B调用Web应用A。
5.2 实验方法及结果
本文围绕单点登录和组合应用访问的单点登录两个功能开展测试实验，为了更好地说明实验结果，将访问过程中涉及到的所有地址按顺序全部打印出来。
（1）单点登录实验
实验方法：用户通过浏览器访问Web应用A，访问成功后，通过浏览器访问Web应用C。
实验结果：单点登录实验结果如表1所示。其中第1行至第4行显示了用户访问Web应用A 的访问过程，用户需要登录然后获取票据，认证通过后成功访问Web应用A；第5 行与第6 行显示了用户访问Web 应用C 的访问过程，用户不需要重新登录即可成功携带票据访问Web应用C，实现了单点登录。
（2）组合应用访问单点登录实验
实验方法：用户通过浏览器访问Web 应用B，Web应用B调用Web应用A。
实验结果：组合应用访问单点登录实验结果如表2所示。表中第1行至第5行显示了用户访问Web应用B的访问过程；第6行显示Web应用B携带PT（代理票据）访问Web应用A，不需用户重新登录即可在Web应用B中访问Web应用A，实现了组合应用访问中的单点登录。
5.3 实验结果分析
通过上节的实验内容及结果，单点登录系统能够基于票据实现用户访问Web应用以及组合应用访问的单点登录。表1的第3行和第6行，用户携带不同的票据（ticket）访问Web应用A和Web应用B，说明了本文提出的单点登录系统能够实现不同域名Web应用的单点登录。在组合应用访问中，表2的第6行Web应用通过代理票据（PT）访问Web应用A，单点登录服务器通过代理票据完成身份认证，实现了组合应用访问中基于代理票据的单点登录。
6 结语
本文对传统的基于票据的单点登录和基于证书的单点登录进行了分析，提出了一种改进的基于票据的单点登录流程，实现了不同域名Web应用的单点登录，引入代理票据实现了组合应用访问的单点登录，同时基于该流程给出了具体的单点登录系统实现方案，无需对Web应用修改配置方案，Web 应用能够灵活便捷地部署该系统。下一步的主要工作是存在多个不同域内的单点登录服务器时，对用户访问Web应用的单点登录进行研究。
教育期刊网 http://www.jyqkw.com
参考文献
[1] 邱航，权勇.基于Kerberos的单点登录系统研究与设计[J].计算机应用，2003，23（7）：142?144.
[2] 林满山，郭荷清.单点登录技术的现状及发展[J].计算机应用，2004（z1）：248?250.
[3] 李小平，阎光伟，王轩峰，等.基于公开密钥基础设施的单点登录系统的设计[J].北京理工大学学报，2002（2）：209?213.
[4] 谭立球，费耀平，李建华.企业信息门户单点登录系统的实现[J].计算机工程，2005，31（17）：102?104.
[5] 茅维华，谢金宝.Web应用单一登录的类Kerberos实现[J].计算机应用与软件，2004，21（2）：87?90.
[6] 续岩，季永志.单点登录技术在Web应用中的研究与实现[J].计算机工程，2006，32（10）：271?273.
作者简介：李晓永（1989—），男，硕士，河南郑州人，硕士研究生。主要研究领域为信息安全、中间件技术。王福喜（1981—），男，硕士，河南商丘人，高级工程师。主要研究领域为信息安全、软件中间件。
