多系统实现单点登陆方案：SSO 单点登陆

1、什么是单点登陆SSO（Single Sign-On）

　　SSO是一种统一认证和受权机制，指访问同一服务器不一样应用中的受保护资源的同一用户，只须要登陆一次，即经过一个应用中的安全验证后，再访问其余应用中的受保护资源时，再也不须要从新登陆验证。

2、单点登陆解决了什么问题

　　解决了用户只须要登陆一次就能够访问全部相互信任的应用系统，而不用重复登陆。

3、单点登陆的技术实现机制

　　以下图所示：

　　

认证后返回给应用系统而不是用户

注（图片所述存在的问题）：单点登陆对用户而言是透明的，它 只是保证子系统之间是相互信任的，也就是说用于访问子系统1，被引导到认证系统，获得一个凭据，这个凭据并非返回给了用户，而是给了子系统1，接着用户 经过子系统1访问子系统2，此次访问会带着刚才的凭据，子系统2收到请求后，发现此次请求有凭据，与是用此凭据到认证系统进行验证，验证合法则准许访问子 系统2，不合法引导到登录界面。

 

　　　　当用户第一次访问应用系统1的时候，由于尚未登陆，会被引导到认证系统中进行登陆；根据用户提供的登陆信息，认证系统进行身 份效验，若是经过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，做为本身认证的凭据，应 用系统接受到请求以后会把ticket送到认证系统进行效验，检查ticket的合法性（4,6）。若是经过效验，用户就能够在不用再次登陆的状况下访问 应用系统2和应用系统3了。

从上图能够看出sso的实现技术点：

　　1）全部应用系统共享一个身份认证系统。

　　　　统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登陆信息和用户信息库相比较，对用户进行登陆认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。

　　2）全部应用系统可以识别和提取ticket信息

　　　　要实现SSO的功能，让用户只登陆一次，就必须让应用系统可以识别已经登陆过的用户。应用系统应该能对ticket进行识别和提取，经过与认证系统的通信，能自动判断当前用户是否登陆过，从而完成单点登陆的功能。

关于统一身份认证机制：以下图

　   ①用户请求访问业务系统。

　　②业务系统在系统中查看是否有对应请求的有效令牌，如有，则读取对应的身份信息，容许其访问；若没有或令牌无效，则把用户重定向到统一身份认证平台，并携带业务系统地址，进入第③步。

　　③在统一身份认证平台提供的页面中，用户输入身份凭证信息，平台验证此身份凭证信息，如有效，则生成一个有效的令牌给用户，进入第④步；若无效，则继续进行认证，直到认证成功或退出为止。

　　④用户携带第③步获取的令牌，再次访问业务系统。

　　⑤业务系统获取用户携带的令牌，提交到认证平台进行有效性检查和身份信息获取。

　　⑥若令牌经过有效性检查，则认证平台会把令牌对应的用户身份信息返回给业务系统，业务系统把身份信息和有效令牌写入会话状态中，容许用户以此身份信息进行业务系统的各类操做；若令牌未经过有效性检查，则会再次重定向到认证平台，返回第③步。

　　经过统一身份认证平台获取的有效令牌，能够在各个业务系统之间实现应用漫游。

4、单点登陆的优势

　　1）提升用户的效率。

　　　　用户再也不被屡次登陆困扰，也不须要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的状况也会减小。 

　　2）提升开发人员的效率。

　　　　SSO 为开发人员提供了一个通用的身份验证框架。实际上，若是 SSO 机制是独立的，那么开发人员就彻底不须要为身份验证操心。他们能够假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。 

　　3）简化管理。

　　　　若是应用程序加入了单点登陆协议，管理用户账号的负担就会减轻。简化的程度取决于应用程序，由于 SSO 只处理身份验证。因此，应用程序可能仍然须要设置用户的属性（好比访问特权）。

5、单点登陆的缺点

　　1）不利于重构

　　　　由于涉及到的系统不少，要重构必需要兼容全部的系统，可能很耗时

　　2） 无人看守桌面

　　　　由于只须要登陆一次，全部的受权的应用系统均可以访问，可能致使一些很重要的信息泄露。

6、登陆验证分析

单点登陆SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登陆后，就不用在其余系统中登陆，也就是用户的一次登陆能获得其余全部系统的信任。单点登陆在 大型网站里使用得很是频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操做或交易可能涉及到几十个子系统的协做，若是每一个子系 统都须要用户认证，不只用户会疯掉，各子系统也会为这种重复认证受权的逻辑搞疯掉。实现单点登陆说到底就是要解决如何产生和存储那个信任，再就是其余系统 如何验证这个信任的有效性，所以要点也就如下几个：

• 存储信任
• 验证信任

只要解决了以上的问题，达到了开头讲得效果就能够说是SSO。最简单实现SSO的方法就是用Cookie，实现流程以下所示：

否则发现以上的方案是把信任存储在客户端的Cookie里，这种方法虽然实现方便但立马会让人质疑两个问题：

• Cookie不安全
• 不能跨域免登

对于第一个问题通常都是经过加密Cookie来处理，第二个问题是硬伤，其实这种方案的思路的就是要把这个信任关系存储在客户端，要实现这个也不必定只能用Cookie，用flash也能解决，flash的Shared Object API就提供了存储能力。

通常说来，大型系统会采起在服务端存储信任关系的作法，实现流程以下所示：

以上方案就是要把信任关系存储在单独的SSO系统（暂且这么称呼它）里，提及来只是简单地从客户端移到了服务端，但其中几个问题须要重点解决：

• 如何高效存储大量临时性的信任数据
• 如何防止信息传递过程被篡改
• 如何让SSO系统信任登陆系统和免登系统

对于第一个问题，通常能够采用相似与memcached的分布式缓存的方案，既能提供可扩展数据量的机制，也能提供高效访问。对于第二个问题，通常 采起数字签名的方法，要么经过数字证书签名，要么经过像md5的方式，这就须要SSO系统返回免登URL的时候对需验证的参数进行md5加密，并带上 token一块儿返回，最后需免登的系统进行验证信任关系的时候，需把这个token传给SSO系统，SSO系统经过对token的验证就能够辨别信息是否 被改过。对于最后一个问题，能够经过白名单来处理，说简单点只有在白名单上的系统才能请求生产信任关系，同理只有在白名单上的系统才能被免登陆。

以上只是提供了些简单的实现技术，但须要强调的是这只是技术实现而已，仅仅是为了解决上面谈到的一些问题，SSO自己来讲并非什么高科技，有了这个认识比较有利于咱们深刻探索SSO。

参考地址：

http://www.cnblogs.com/yupeng/archive/2012/05/24/2517317.html，

http://blog.csdn.net/cutesource/article/details/5838693