基于Cookie的单点登录（SSO）系统介绍

SSO的概念：

       单点登录SSO（Single Sign-On）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。

SSO的用途：

      目前的企业应用环境中，往往有很多的应用系统，如办公自动化（OA）系统，财务管理系统，档案管理系统，信息查询系统等等。这些应用系统服务于企业的信息化建设，为企业带来了很好的效益。但是，用户在使用这些应用系统时，并不方便。用户每次使用系统，都必须输入用户名称和用户密码，进行身份验证；而且应用系统不同，用户账号就不同，用户必须同时牢记多套用户名称和用户密码。特别是对于应用系统数目较多，用户数目也很多的企业，这个问题尤为突出。问题的原因并不是系统开发出现失误，而是缺少整体规划，缺乏统一的用户登录平台，使用SSO技术可以解决以上这些问题

SSO的好处：

1. 方便用户：从用户实际使用角度考虑
   

         用户使用应用系统时，能够一次登录，多次使用。用户不再需要每次输入用户名称和用户密码，也不需要牢记多套用户名称和用户密码。单点登录平台能够改善用户使用应用系统的体验。 

2. 方便管理员：从日常维护管理角度考虑
         系统管理员只需要维护一套统一的用户账号，方便、简单。相比之下，系统管理员以前需要管理很多套的用户账号。每一个应用系统就有一套用户账号，不仅给管理上带来不方便，而且，也容易出现管理漏洞。
3. 简化应用系统开发：从应用扩展角度考虑 
   
         开发新的应用系统时，可以直接使用单点登录平台的用户认证服务，简化开发流程。单点登录平台通过提供统一的认证平台，实现单点登录。因此，应用系统并不需要开发用户认证程序。   

SSO架构及原理：

     单点登录的实质就是安全上下文（Security Context）或凭证（Credential）在多个应用系统之间的传递或共享。当用户登录系统时，客户端根据用户的凭证（例如用户名和密码）为用户建立一个安全上下文，安全上下文包含用于验证用户的安全信息，系统用这个安全上下文和安全策略来判断用户是否具有访问系统资源的权限。

        上图中的流程反映出当应用系统调用信息平台所提供的SSO登录过程中的步骤。从上图中，当应用系统或用户访问应用系统的单点登录页面（aspx、JSP、Servlet、ASP）时，应用系统需要检查用户当前请求中是否包含信息平台的单点登录信息（如Cookie）。如果当前请求中包含SSO Token，应用系统应该获取SSO Token的数据，并把SSO Token的数据通过信息平台提供的WebService(或其它方式)对其进行验证。如果当前请求中不包含SSO Token，应用系统可以直接返回登录错误信息给客户端。应用系统可以根据信息平台对SSO Token的验证结果进行相应的处理。

 

SSO的技术：

1. 基于cookies实现：
        利用浏览同域名之间自动传递cookies机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然cookies本身不跨域，但可以利用它实现跨域的SSO。如：代理、暴露SSO令牌值等。
2. Broker-based(基于经纪人)
         这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的“第三方”。例如 集团SMAP 、Kerberos、Sesame、IBM KryptoKnight（凭证库思想）等
3. Agent-based(基于代理)
         在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如, 它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个“翻译”；例如 SSH等。
4. Token-based
         现在被广泛使用的口令认证，比如FTP，邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用
5. 基于网关
6. 基于安全断言标记语言(SAML)实现
        SAML（Security Assertion Markup Language，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。

 

笔者实现的单点登录：

      笔者基于实现成本最低，当然安全系数是最低的基于Cookie的单点登录系统。单点登录的交互过程如下图（图画的不专业，见笑了）：

 

 

简单描述一个笔者的实现过程

步骤1：用户通过浏览器访问系统A，验证是否有SSO信息

A,系统A首先读取客户端的cookie,若cookie的值为空则转步骤2，否则继续往下判断；
B,读取系统A的Session，若Session与cookie的token值相同，则直接返回用户所访问的页面；若不同则继续转C步骤处理；

C,调用SSO的Web服务【这期间需要对调用web服务的参数如帐号密码进行验证，也可以对访问IP或IP段做访问控制】，验证cookie中的值包含的时间戳是否过期，若过期则转步骤2；若未过期则判断SSO是否被篡改，篡改则转步骤2，未篡改则记录**用户于**时间登录了**系统（还可以记录客户端的相关信息，如OS，Browser，IP等信息）转步骤D；
D，返回用户信息，重新记录Session及cookie信息。

步骤2：无SSO信息，返回重定向信息至用户端，转步骤3

步骤3：用户端收到信息后，跳转至单点登录的统一认证界面

步骤4：单点登录站点接收到页面请求后，将统一认证界面返回给用户

步骤5：用户输入帐号密码进行登录

步骤6：单点服务到数据库中验证用户的信息

步骤7：返回Token信息，将token写入cookie

       若验证通过，则将时间戳信息+加密后的用户信息作为token值写入cookie。其中，token的时间戳加上超时时间的1/3>=当前时间，则重新生成一个时间戳及Des加解密用的key、iv；从而保证用户在操作页面时得以延长超时时间。

步骤8：认证通过后系统又重新定到系统A

      在刚重定向至系统A时，由于系统A无Session系统，故仍会执行步骤1的判断，调用Web服务去验证token信息（这一步有点重复，不知各位大侠有何更好解决办法。若通过系统A自身调用SSO接口进行验证并记录session或cookie则不存在这个问题），直到在返回后重写cookie。

步骤9：用户通过系统A的链接进入系统B

步骤10：系统B首先判断服务端的Session及客户端的Cookie的Token是否一致。

      由于系统B第一次被某个用户访问，故无Session信息，只有Cookie信息 

步骤11：调用SSO的Web服务将Token信息传递给SSO进行验证

步骤12：校验Token信息

      判断token是否过期，若过期则跳转至SSO登录；未过期则对token进行解密，若不能解密，则token被篡改，重新跳转SSO登录（判断过程跟步骤1一致）

步骤13：返回Token信息,系统B写Session及Cookie

步骤14:将用户向系统B请求的页面返回给用户

 

   以上是本人是根据现在整的单点登录整理出来的思路，有点闭门造车的味道，东西也被我粗制滥造出来了，估计在中小企业还能发挥所长。简单给大家展示一下SSO统一认证的“庐山面目”，如下：

 

       上面的介绍步骤稍微粗略简单了些，还有一些相关的细枝末节没谈及。由于本人非SSO领域的行家，不少地方很不专业，难免被大家贻笑大方，恳请各位前辈们，同行们多多指教。