SSO单点登录 in Action.docx
- 文档编号:30120206
- 上传时间:2023-08-05
- 格式:DOCX
- 页数:19
- 大小:498.56KB
SSO单点登录 in Action.docx
《SSO单点登录 in Action.docx》由会员分享,可在线阅读,更多相关《SSO单点登录 in Action.docx(19页珍藏版)》请在冰豆网上搜索。
SSO单点登录inAction
SSO(SingleSign-on)inAction
1.SSO原理浅谈
SSO是一个非常大的主题,我对这个主题有着深深的感受,自从广州UserGroup的论坛成立以来,无数网友都在尝试使用开源的CAS,Kerberos也提供另外一种方式的SSO,即基于Windows域的SSO,还有就是从2005年开始一直兴旺不衰的SAML。
如果将这些免费的SSO解决方案与商业的Tivoli或Siteminder或RSASecureSSO产品做对比,差距是存在的。
毕竟,商业产品的安全性和用户体验都是无与伦比的,我们现在提到的SSO,仅仅是WebSSO,即Web-SSO是体现在客户端;另外一种SSO是桌面SSO,例如,只需要作为Administrator登录一次windows2000,我便能够在使用MSN/QQ的时候免去登录的环节(注意,这不是用客户端软件的密码记忆功能),是一种代理用户输入密码的功能。
因此,桌面SSO是体现在OS级别上。
今天,当我们提起SSO的时候,我们通常是指WebSSO,它的主要特点是,SSO应用之间走Web协议(如HTTP/SSL),并且SSO都只有一个登录入口。
简单的SSO的体系中,会有下面三种角色:
1、User(多个)
2、Web应用(多个)
3、SSO认证中心(1个)
虽然SSO实现模式千奇百怪,但万变不离其宗:
Web应用不处理User的登录,否则就是多点登陆了,所有的登录都在SSO认证中心进行。
SSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是张三/李四。
SSO认证中心和所有的Web应用建立一种信任关系,SSO认证中心对用户身份正确性的判断会通过某种方法告之Web应用,而且判断结果必须被Web应用信任。
2.CAS的基本原理
CAS(CentralAuthenticationService)是Yale大学发起的一个开源项目,据统计,大概每10个采用开源构建WebSSO的Java项目,就有8个使用CAS。
对这些统计,我虽然不以为然,但有一点可以肯定的是,CAS是我认为最简单实效,而且足够安全的SSO选择。
本节主要分析CAS的安全性,以及为什么CAS被这样设计,带着少许密码学的基础知识,我希望有助于读者对CAS的协议有更深层次的理解。
2.1CAS的结构体系
从结构体系看,CAS包含两部分:
CASServer
CASServer负责完成对用户的认证工作,CASServer需要独立部署,有不止一种CASServer的实现,YaleCASServer和ESUPCASServer都是很不错的选择。
CASServer会处理用户名/密码等凭证(Credentials),它可能会到数据库检索一条用户帐号信息,也可能在XML文件中检索用户密码,对这种方式,CAS均提供一种灵活但同一的接口/实现分离的方式,CAS究竟是用何种认证方式,跟CAS协议是分离的,也就是,这个认证的实现细节可以自己定制和扩展。
CASClient
CASClient负责部署在客户端(注意,我是指Web应用),原则上,CASClient的部署意味着,当有对本地Web应用的受保护资源的访问请求,并且需要对请求方进行身份认证,Web应用不再接受任何的用户名密码等类似的Credentials,而是重定向到CASServer进行认证。
目前,CASClient支持(某些在完善中)非常多的客户端,包括Java、.Net、ISAPI、Php、Perl、uPortal、Acegi、Ruby、VBScript等客户端,几乎可以这样说,CAS协议能够适合任何语言编写的客户端应用。
2.2CAS协议
剖析协议就像剖析设计模式,有些时候,协议让人摸不着头脑。
CAS的代理模式要相对复杂一些,它引入了一些新的概念,我希望能够在这里描述一下其原理,有助于读者在配置和调试CASSSO有更清晰的思路。
如果没记错,CAS协议应该是由DrewMazurek负责可开发的,从CASv1到现在的CASv3,整个协议的基础思想都是基于Kerberos的票据方式。
CASv1非常原始,传送一个用户名居然是”yes\ndavid.turing”的方式,CASv2开始使用了XML规范,大大增强了可扩展性,CASv3开始使用AOP技术,让Spring爱好者可以轻松配置CASServer到现有的应用环境中。
CAS是通过TGT(TicketGrantingTicket)来获取ST(ServiceTicket),通过ST来访问服务,而CAS也有对应TGT,ST的实体,而且他们在保护TGT的方法上虽然有所区别,但是,最终都可以实现这样一个目的——免去多次登录的麻烦。
下面,我们看看CAS的基本协议框架:
2.1.1基础协议
CAS基础模式
上图是一个最基础的CAS协议,CASClient以Filter方式保护Web应用的受保护资源,过滤从客户端过来的每一个Web请求,同时,CASClient会分析HTTP请求中是否包请求ServiceTicket(上图中的Ticket),如果没有,则说明该用户是没有经过认证的,于是,CASClient会重定向用户请求到CASServer(Step2)。
Step3是用户认证过程,如果用户提供了正确的Credentials,CASServer会产生一个随机的ServiceTicket,然后,缓存该Ticket,并且重定向用户到CASClient(附带刚才产生的ServiceTicket),ServiceTicket是不可以伪造的,最后,Step5和Step6是CASClient和CASServer之间完成了一个对用户的身份核实,用Ticket查到Username,因为Ticket是CASServer产生的,因此,所以CASServer的判断是毋庸置疑的。
该协议完成了一个很简单的任务,就是User(david.turing)打开IE,直接访问helloservice应用,它被立即重定向到CASServer进行认证,User可能感觉到浏览器在helloservcie和casserver之间重定向,但User是看不到,CASClient和CASServer相互间的ServiceTicket核实(Validation)过程。
当CASServer告知CASClient用户ServiceTicket对应确凿身份,CASClient才会对当前Request的用户进行服务。
2.2.2CAS如何实现SSO
当我们的Web时代还处于初级阶段的时候,SSO是通过共享cookies来实现,比如,下面三个域名要做SSO:
如果通过CAS来集成这三个应用,那么,这三个域名都要做一些域名映射,
http:
//blogjava.cas.org/
http:
//matrix.cas.org/
http:
//csdn.cas.org/
因为是同一个域,所以每个站点都能够共享基于cas.org的cookies。
这种方法原始,不灵活而且有不少安全隐患,已经被抛弃了。
CAS可以很简单的实现跨域的SSO,因为,单点被控制在CASServer,用户最有价值的TGC-Cookie只是跟CASServer相关,CASServer就只有一个,因此,解决了cookies不能跨域的问题。
回到CAS的基础协议图,当Step3完成之后,CASServer会向User发送一个Ticketgrantingcookie(TGC)给User的浏览器,这个Cookie就类似Kerberos的TGT,下次当用户被Helloservice2重定向到CASServer的时候,CASServer会主动Get到这个TGCcookie,然后做下面的事情:
1、如果User的持有TGC且其还没失效,那么就走基础协议图的Step4,达到了SSO的效果。
2、如果TGC失效,那么用户还是要重新认证(走基础协议图的Step3)。
2.2.2CAS的代理模式
模式1已经能够满足大部分简单的SSO应用,现在,我们探讨一种更复杂的情况,即用户访问helloservice,helloservice又依赖于helloservice2来获取一些信息,如同:
Userhelloservicehelloservice2
这种情况下,假设helloservice2也是需要对User进行身份验证才能访问,那么,为了不影响用户体验(过多的重定向导致User的IE窗口不停地闪动),CAS引入了一种Proxy认证机制,即CASClient可以代理用户去访问其它Web应用。
代理的前提是需要CASClient拥有用户的身份信息(类似凭据)。
与其说之前我们提到的TGC是用户持有对自己身份信息的一种凭据,则这里的PGT就是CASClient端持有的对用户身份信息的一种凭据。
凭借TGC,User可以免去输入密码以获取访问其它服务的ServiceTicket,所以,这里,凭借PGT,Web应用可以代理用户去实现后端的认证,而无需前端用户的参与。
如下面的CASProxy图所示,CASClient在基础协议之上,提供了一个额外的PGTURL给CASServer,于是,CASServer可以通过PGTURL提供一个PGT给CASClient。
初学者可能会对上图的PGTURL感到迷惑,或者会问,为什么要这么麻烦,要通过一个额外的URL(而且是SSL的入口)去传递PGT?
如果直接在Step6返回,则连用来做对应关系的PGTIOU都可以省掉。
PGTIOU设计是从安全性考虑的,非常必要,CAS协议安全性问题我会在后面一节介绍。
于是,CASClient拿到了PGT(PGTIOU-85…..ti2td),这个PGT跟TGC同样地关键,CASClient可以通过PGT向后端Web应用进行认证。
如下图所示,Proxy认证与普通的认证其实差别不大,Step1,2与基础模式的Step1,2几乎一样,唯一不同的是,Proxy模式用的是PGT而不是TGC,是ProxyTicket(PT)而不是ServiceTicket。
最终的结果是,helloservice2明白helloservice所代理的客户是David.Turing同学,同时,根据本地策略,helloservice2有义务为PGTURL=http:
//helloservice/proxy服务(PGTURL用于表示一个Proxy服务),于是它传递数据给helloservice。
这样,helloservice便完成一个代理者的角色,协助User返回他想要的数据。
代理认证模式非常有用,它也是CAS协议v2的一个最大的变化,这种模式非常适合在复杂的业务领域中应用SSO。
因为,以前我们实施SSO的时候,都是假定以IEUser为SSO的访问者,忽视了业务系统作为SSO的访问者角色。
2.3CAS安全性
CAS的安全性是一个非常重要的Topic。
CAS从v1到v3,都很依赖于SSL,它假定了这样一个事实,用户在一个非常不安全的网络环境中使用SSO,Hacker的Sniffer会很容易抓住所有的HttpTraffic,包括通过Http传送的密码甚至Ticket票据。
2.3.1TGC/PGT安全性
对于一个CAS用户来说,最重要是要保护它的TGC,如果TGC不慎被CASServer以外的实体获得,Hacker能够找到该TGC,然后冒充CAS用户访问所有授权资源。
SSO的安全性问题比普通应用的安全性还要严重,因为SSO存在一种门槛效应。
以前即使Hacker能够截获用户在Web应用A的密码,它也未必能知道用户在Web应用B的密码,但SSO让Hacker只需要截获TGC(突破了门槛),即能访问所有与该用户相关的所有应用系统。
PGT跟TGC的角色是一样的,如果被Hacker获得,后果可想而知。
从基础模式可以看出,TGC是CASServer通过SSL方式发送给终端用户,因此,要截取TGC难度非常大,从而确保CAS的安全性。
因此,某些人认为CAS可以不使用SSL的想法需要更正一下,CAS的传输安全性仅仅依赖与SSL。
跟Kerberos一样TGT,TGC也有自己的存活周期。
下面是CAS的web.xml中,通过grantingTimeout来设置CASTGC存活周期的参数,参数默认是120分钟,在合适的范围内设置最小值,太短,会影响SSO体验,太长,会增加安全性风险。
TGC面临的风险主要并非传输窃取。
比如你登陆了之后,没有Logout,离开了电脑,别人就可以打开你的浏览器,直接访问你授权访问的应用),设置一个TGC的有效期,可以减少被别人盗用,或者被Hacker入侵你的电脑直接获取你系统目录下的TGCCookie。
2.3.2ServiceTicket/ProxyTicket安全性
首要明白,ServiceTicket是通过Http传送的,以为着所网络中的其他人可以Sniffer到其他人的Ticket。
CAS协议从几个方面让ServiceTicket变得更加安全。
ServiceTicket只能使用一次。
CAS协议规定,无论ServiceTicket验证是否成功,CASServer都会将服务端的缓存中清除该Ticket,从而可以确保一个ServiceTicket被使用两次。
ServiceTicket在一段时间内失效。
假设用户拿到ServiceTicket之后,他请求helloservice的过程又被中断了,ServiceTicket就被空置了,事实上,此时,ServiceTicket仍然有效。
CAS规定ServiceTicket只能存活一定的时间,然后CASServer会让它失效。
通过在web.xml中配置下面的参数,可以让ServiceTicket在多少秒内失效。
该参数在业务应用的条件范围内,越小越安全。
l ServiceTicket是基于随机数生成的。
ServiceTicket必须足够随机,如果ServiceTicket生成规则被猜出(如果你使用了ST+Helloservice+自增序列的方式,Hacker就可以构造下一个Ticket),Hacker就等于绕过CAS认证,直接访问所有服务。
3.CAS以外的其他开源SSO方案
除了CAS之外,还有很多开源的SSO方案,采用何种方案跟用户的应用环境有比较大的关系。
SSO的优劣一般要考虑易用性,安全性,性能,扩展性等因素。
3.1JOSSO
经常听到别人讨论JOSSO,JOSSO(www.josso.org)是我很早就用过的SSO开源项目,我后来抛弃了它,因为它存在比较多缺点,下面我们来看看:
1、没有将后台认证与SSO分离,过分强调JAAS,Axis等
JOSSO官方网站发布了JOSSO三个基准:
StandardBased
JOSSOsecurityinfrastructureisbasedonJAAS(JavaAuthenticationandAuthorizationService)
JOSSOuseswebservicesimplementingAxisasthedistributedinfrastructure.
JOSSOusesStrutsandJSPstandards
这些标准可以看到JOSSO的适应性存在较大的限制,因为SSO其实并不关心认证细节,作为一个开源项目,不应该引用过多的技术,如Axis,因为这个世界还有很多人用Xfire。
2、没有描述SSO协议的UseCase图
从JOSSO的网站,似乎都看不到一个SSO的UseCase,容易让那些关注安全性的大型项目负责人感到忧虑。
3、缺乏广泛的SSO客户端支持
JOSSO的支持的客户端比较少,这个跟他的MememberTeam、ContributorTeam有比较大的关系。
4、缺乏成功案例
读者使用任何SSO开源方案之前,有必要先了解次方案的成功案例,CAS全球有50多个大学在使用(大学对SSO的要求往往更复杂)成功案例,这方面,JOSSO跟CAS存在很大的差距。
5、不支持跨域的落后设计
当然,JOSSO不支持跨域是因为它使用了共享cookie,下面的话截取于JOSSO的官方文档:
JOSSOusesasessionHTTPcookietokeeptrackoftheSSOsessionidentifier.Thiscookielivesaslongasthebrowserwindowisopen,beingsentonlyinrequestsassociatedwiththedomainthatgeneratedit.ThismeansthatallJOSSOpartnerapplicationsmustbeaccessedusingthesamedomain.
这段话给我们一个提示,如果设计SSO的时候,使用了cookie来在SSOServer和SSOAgent(相当于CAS的CASClient)之间共享用户信息,那么这个协议是无法突破跨域限制的。
因为当多个SSOAgent如果不使用同一个域名,也就是M和IBM.com无法共享同一个cookie,JOSSO采用了一种DNS技巧,即使用M和来共享cookie,但这带来的问题同样很多,尤其是业务系统本身存在一些对域名限制的业务逻辑的时候,需要改动原来业务系统,这不是一件好受的事情。
3.2CoSign
CoSign原先是Michigan大学的一个SSO项目,CoSign是一个很不错的设计,但是它跟CAS比较相似,都是基于Kerberos方式的协议,一个最大的不同是CoSign的SSOServer是基于CGI(JavaFans更多会选择CAS),对C/C++的群体应该是一个不错的选择。
CoSign协议的UseCase跟CAS很相似,CoSign的客户端虽然也支持J2EE/Apache/MSAPI(IIS),但它的Server端使用C来编写,影响了在Java群体中的使用。
CoSign是一个不错的选择,可能是因为本人比较喜欢KerberosModel的原因吧。
3.3WebAuth
WebAuth是一种早期的SSO方案,它的WebServer是用perl来编写的,客户端支持Apache,C++,Perl等,当然,WebAuth推出的时候,Java并不是很流行,现在,要让WebAuth跟众多的Java产品结合不是一件容易的事情。
WebAuth的协议适用了ShareSecret,即SSOServer和SSOClient之间存在一个对称密钥(symmetrickey)。
SSOServer和SSOClient之间的信任关系通过这个Key来保障。
上图中展示了一个WebAuth的基本模式,Client就是浏览器用户,GenericWebService是SSOClient,WebAuthService和AuthService可以看作是SSOServer。
当浏览器发起一个对Web应用的访问请求时,这个请求未授权,因此被重定向到WebAuthService进行认证,认证的结果是获得一个经过symmetrickey加密的token,而这个Token只有GenericWebService能够解密,因此,Web应用能够知道浏览器用户的身份。
使用对称加密来共享用户身份信息存在一定的安全隐患,首先是WebAuthService如何保护这些对称密钥(保护密钥安全本身是一件很困难的事情),一旦这些对称密钥被泄漏了,Token就可以被随意篡改。
另外,由于Token本身是基于Cookie方式发送,因此,只要Hacker能够复制这个Token,他同样可以访问其他应用。
如果不考虑安全性问题,WebAuth的效率应该比其他SSO方案要高,因为它的协议没有CAS/CoSign那么复杂,WebAuth中,SSOServer不需要跟SSOClient通讯以确认用户的身份,用户的身份就放在Token中。
4.SAML
SAML是OASIS制定的一种安全性断言标记语言,它用于在复杂的环境下交换用户的身份识别信息。
在SAML诞生之前,如果想在Websphere、Weblogic和SunONE等之间实现SSO,我们必须分别实现一个适配层,来达成一种相互理解的协议,在该协议上,产品能够共享各自的用户认证/授权信息。
SAML诞生之后,我们免去了这种烦恼。
可以预计,将来大部分产品都可以实现基于SAML的联邦服务。
事实伤,SAML已经在很多商业/开源产品中得到实现,包括:
IBMTivoliAccessManager
BEAWeblogic
OblixNetPoint
SunONEIdentityServer
Baltimore,SelectAcc
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SSO单点登录 in Action SSO 单点 登录
![提示](https://static.bdocx.com/images/bang_tan.gif)