Yale CAS实现原理及其基础协议_第1页
Yale CAS实现原理及其基础协议_第2页
Yale CAS实现原理及其基础协议_第3页
Yale CAS实现原理及其基础协议_第4页
Yale CAS实现原理及其基础协议_第5页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

YaleCAS实现原理及其基础协议CAS(CentralAuthenticationService)是Yale大学发起的一个开源项目,据统计,大概每10个采用开源构建WebSSO的Java项目,就有8个使用CAS。对这些统计,我虽然不以为然,但有一点可以肯定的是,CAS是我认为最简单实效,而且足够安全的SSO选择。本节主要分析CAS的安全性,以及为什么CAS被这样设计,带着少许密码学的基础知识,我希望有助于读者对CAS的协议有更深层次的理解。从结构体系看,CAS包含两部分:lCASServerCASServer负责完成对用户的认证工作,CASServer需要独立部署,有不止一种CASServer的实现,YaleCASServer和ESUPCASServer都是很不错的选择。CASServer会处理用户名/密码等凭证(Credentials),它可能会到数据库检索一条用户帐号信息,也可能在XML文件中检索用户密码,对这种方式,CAS均提供一种灵活但同一的接口/实现分离的方式,CAS究竟是用何种认证方式,跟CAS协议是分离的,也就是,这个认证的实现细节可以自己定制和扩展。lCASClientCASClient负责部署在客户端(注意,我是指Web应用),原则上,CASClient的部署意味着,当有对本地Web应用的受保护资源的访问请求,并且需要对请求方进行身份认证,Web应用不再接受任何的用户名密码等类似的Credentials,而是重定向到CASServer进行认证。目前,CASClient支持(某些在完善中)非常多的客户端,包括Java、.Net、ISAPI、Php、Perl、uPortal、Acegi、Ruby、VBScript等客户端,几乎可以这样说,CAS协议能够适合任何语言编写的客户端应用。剖析协议就像剖析设计模式,有些时候,协议让人摸不着头脑。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的基本协议框架:基础协议CASServerShip://caservcr:S080Ring'sbbg.:openssl-b/ogjava.-netHLLp://hcllo«crvLCCCASServerShip://caservcr:S080Ring'sbbg.:openssl-b/ogjava.-netHLLp://hcllo«crvLCC5.Srrviuc=hclitwerviut,Tiukcl=1234567S9O4.Service—hcll<»scrvicc、TiekeL—]234567^00CAS基础模式上图是一个最基础的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的用户进行服务。CAS如何实现SSO当我们的Web时代还处于初级阶段的时候,SSO是通过共享cookies来实现,比如,下面三个域名要做SSO:http://www.ma如果通过CAS来集成这三个应用,那么,这三个域名都要做一些域名映射,http://http://mahttp://因为是同一个域,所以每个站点都能够共享基于的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)。CAS的代理模式模式1已经能够满足大部分简单的SSO应用,现在,我们探讨一种更复杂的情况,即用户访问helloservice,helloservice又依赖于helloservice2来获取一些信息,如同:Userahelloserviceahelloservice2这种情况下,假设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。CASClientHCASClientHIipri'/h^rioKCTv5-2.POTIOU=10«)0PPOT-4-Service=HellL-Kscndcc.Ticket=1234567R90

PGTURL-hcll0serv]ce:KM35-LUscinuLue-DsvllI.Turing,PGT[OU-]OOM耳.Sx^jcf=heJkiscrvictnTicket=KT-«*56-l.^^UdLkgdrBOTW1?bXS初学者可能会对上图的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返回他想要的数据。

CASServerLlun:.7cascrvcr:fi443CASServerLlun:.7cascrvcr:fi443Gd<5vid.tuning'sbbg:opens或&ogja畑n直匚;VW

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论