您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 信息化管理 > SSO解决方案和技术路线
CAS配置手册1SSO原理浅谈SSO是一个非常大的主题,无数网友都在尝试使用开源的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应用信任。2CAS基本原理CAS(CentralAuthenticationService)是Yale大学发起的一个开源项目,据统计,大概每10个采用开源构建WebSSO的Java项目,就有8个使用CAS。对这些统计,我虽然不以为然,但有一点可以肯定的是,CAS是我认为最简单实效,而且足够安全的SSO选择。本节主要分析CAS的安全性,以及为什么CAS被这样设计,带着少许密码学的基础知识,我希望有助于读者对CAS的协议有更深层次的理解。2.1CAS的结构体系从结构体系看,CAS包含两部分:CASServerCASServer负责完成对用户的认证工作,CASServer需要独立部署,有不止一种CASServer的实现,YaleCASServer和ESUPCASServer都是很不错的选择。CASServer会处理用户名/密码等凭证(Credentials),它可能会到数据库检索一条用户帐号信息,也可能在XML文件中检索用户密码,对这种方式,CAS均提供一种灵活但同一的接口/实现分离的方式,CAS究竟是用何种认证方式,跟CAS协议是分离的,也就是,这个认证的实现细节可以自己定制和扩展。CASClientCASClient负责部署在客户端(注意,我是指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非常原始,传送一个用户名居然是”yesndavid.turing”的方式,CASv2开始使用了XML规范,大大增强了可扩展性,CASv3开始使用AOP技术,让Spring爱好者可以轻松配置CASServer到现有的应用环境中。CAS是通过TGT(TicketGrantingTicket)来获取ST(ServiceTicket),通过ST来访问服务,而CAS也有对应TGT,ST的实体,而且他们在保护TGT的方法上虽然有所区别,但是,最终都可以实现这样一个目的——免去多次登录的麻烦。下面,我们看看CAS的基本协议框架:2.2.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:://来集成这三个应用,那么,这三个域名都要做一些域名映射,://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.3CAS的代理模式模式1已经能够满足大部分简单的SSO应用,现在,我们探讨一种更复杂的情况,即用户访问helloservice,helloservice又依赖于helloservice2来获取一些信息,如同:Useràhelloserviceàhelloservice2这种情况下,假设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=服务(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票据(配置生命周期id规则自己定服务端)。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的
本文标题:SSO解决方案和技术路线
链接地址:https://www.777doc.com/doc-4190508 .html