SSO单点登陆技术总结

SSOSingleSignOn-sso单点登陆技术总结作者：温德亮修订历史记录：*A-增加M-修订D-删除变更版本号日期变更类型（A*M*D）修改人摘要备注V0.12011-08-22A温德亮1SSO解析SSO英文全称SingleSignOn，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录机制。它是目前比较流行的企业业务整合的解决方案之一。在市面流传深广并且技术非常流行，是重要门户网站、服务网站解决综合性客户验证，是一套非常成熟的解决方案。2SSO实现机制2.1机制解释现今提起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应用信任。当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录。根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。要实现SSO，需要以下主要的功能：2.2所有应用型系统共享身份认证统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。而与SSO联合开发的这里的是Ldap进行开发。Ldap以后会介绍到。2.3所有应用系统能够识别与提取Ticket信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。另外：1、单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，事实上，只要统一认证系统，统一ticket的产生和效验，无论用户信息存储在什么地方，都能实现单点登录。2、统一的认证系统并不是说只有单个的认证服务器认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别3WEB系统SSO实现原理用户在访问页面1的时候进行了登录，但是客户端的每个请求都是单独的连接，当客户再次访问页面2的时候，如何才能告诉Web服务器，客户刚才已经登录过了呢？浏览器和服务器之间有约定：通过使用cookie技术来维护应用的状态。Cookie是可以被Web服务器设置的字符串，并且可以保存在浏览器中。当浏览器访问了页面1时，web服务器设置了一个cookie，并将这个cookie和页面1一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2的时候会把这个cookie也带上，Web服务器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。Web-SSO完全可以利用Cookie结束来完成用户登录信息的保存，将浏览器中的Cookie和上文中的Ticket结合起来，完成SSO的功能。为了完成一个简单的SSO的功能，需要两个部分的合作：1、统一的身份认证服务。2、修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效验。很多的网站都有用到SSO技术,新浪的用户登录也是用到的SSO技术.4总结SSO优点4.1减少用户在不同系统中登陆耗费时间4.2减少用户登陆出错的可能性4.3实现安全的同时避免了处理和保存多套系统用户的认证信息4.4减少了系统管理员工作量，减少增加、删除用户和修改用户权限时间4.5增加用户安全性，避免用户帐号遗失4.6系统管理员可以更好管理用户，包括可以通过直接诶禁止和删除用户来取消该用户对所有系统资源的访问权限与对系统资源的消耗5实现SSO通用几种方式5.1COOKIES实现基于cookies实现,需要注意如下几点:如果是基于两个域名之间传递sessionid的方法可能在windows中成立,在unix&linux中可能会出现问题;可以基于数据库实现;在安全性方面可能会作更多的考虑。另外,关于跨域问题,虽然cookies本身不跨域,但可以利用它实现跨域的SSO。5.2Kerberos实现Broker-based(基于经纪人),例如Kerberos等;这种技术的特点就是,有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价,并为认证提供一个公共和独立的第三方。例如Kerberos,Sesame,IBMKryptoKnight(凭证库思想)等。Kerberos是由麻省理工大学发明的安全认证服务,当前版本V5,已经被UNIX和Windows作为默认的安全认证服务集成进操作系统。5.3Agent-based实现Agent-based(基于代理人)在这种解决方案中,有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如,它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面,在服务器的认证系统和客户端认证方法之间充当一个翻译。例如SSH等。5.4Token-based实现Token-based,例如SecurID,WebID,现在被广泛使用的口令认证,比如FTP,邮件服务器的登录认证,这是一种简单易用的方式,实现一个口令在多种应用当中使用。5.5AGENTANDBROKER-BASED实现基于网关AgentandBroker-based,这里不作介绍。5.6CAS实现基于安全断言标记语言(SAML)实现,SAML(SecurityAssertionMarkupLanguage,安全断言标记语言)的出现大大简化了SSO,并被OASIS批准为SSO的执行标准。开源组织OpenSAML实现了SAML规范。CAS由耶鲁大学开发的单点登录系统(SSO,singlesign-on),应用广泛,具有独立于平台的,易于理解,支持代理功能。现如今实现SSO技术都采用CAS技术的单点登录。如：当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统2的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。6CAS实现SSO单点登陆6.1CAS来源CAS(CentralAuthenticationService)是Yale大学发起的一个开源项目，据统计，大概每10个采用开源构建WebSSO的Java项目，就有8个使用CAS。对这些统计，我虽然不以为然，但有一点可以肯定的是，CAS是我认为最简单实效，而且足够安全的SSO选择。比起其他实现更适合。6.2CAS两种架构6.2.1CASSERVERCASServer负责完成对用户的认证工作，CASServer需要独立部署，有不止一种CASServer的实现，YaleCASServer和ESUPCASServer都是很不错的选择。CASServer会处理用户名/密码等凭证(Credentials)，它可能会到数据库检索一条用户帐号信息，也可能在XML文件中检索用户密码，对这种方式，CAS均提供一种灵活但同一的接口/实现分离的方式，CAS究竟是用何种认证方式，跟CAS协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。6.2.2CASClientCASClient负责部署在客户端（注意，我是指Web应用），原则上，CASClient的部署意味着，当有对本地Web应用的受保护资源的访问请求，并且需要对请求方进行身份认证，Web应用不再接受任何的用户名密码等类似的Credentials，而是重定向到CASServer进行认证。目前，CASClient支持（某些在完善中）非常多的客户端，包括Java、.Net、ISAPI、Php、Perl、uPortal、Acegi、Ruby、VBScript等客户端，几乎可以这样说，CAS协议能够适合任何语言编写的客户端应用。6.3CAS协议与实现剖析协议就像剖析设计模式，有些时候，协议让人摸不着头脑。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的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。6.3.1基础协议上图是一个最基础的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的用户进行服务。6.3.2CAS如何实现SSO当我们的Web时代还处于初级阶段的时候，SSO是通过共享cookies来实现，比如，下面三个域名要做SSO：://来集