SSO 基于Cookie+fliter实现单点登录（SSO）：工作原理

Posted 2020-06-14

SSO的概念：

       单点登录SSO（Single Sign-On）是身份管理中的一部分。

SSO的一种较为通俗的定义是：SSO是指訪问同一server不同应用中的受保护资源的同一用户，仅仅须要登录一次，即通过一个应用中的安全验证后，再訪问其它应用中的受保护资源时，不再须要又一次登录验证。

SSO的用途：

      眼下的企业应用环境中。往往有非常多的应用系统，淘宝、天猫、爱淘宝等等产品和如办公自己主动化（OA）系统，財务管理系统。档案管理系统，信息查询系统等等。这些应用系统服务于企业的信息化建设，为企业带来了非常好的效益。可是，用户在使用这些应用系统时，并不方便。

用户每次使用系统，都必须输入username称和用户password。进行身份验证；并且应用系统不同，用户账号就不同，用户必须同一时候牢记多套username称和用户password。

特别是对于应用系统数目较多，用户数目也非常多的企业。这个问题尤为突出。问题的解决办法并非系统开发出现失误。而是缺少总体规划。缺乏统一的用户登录平台，使用SSO技术能够解决以上这些问题

SSO的优点：

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

         用户使用应用系统时，可以一次登录，多次使用。用户不再须要每次输入username称和用户password，也不须要牢记多套username称和用户password。单点登录平台可以改善用户使用应用系统的体验。

    

2. 方便管理员：从日常维护管理角度考虑
         系统管理员仅仅须要维护一套统一的用户账号。方便、简单。

   相比之下，系统管理员曾经须要管理非常多套的用户账号。每个应用系统就有一套用户账号。不仅给管理上带来不方便，并且。也easy出现管理漏洞。

3. 简化应用系统开发：从应用扩展角度考虑 
   
         开发新的应用系统时。能够直接使用单点登录平台的用户认证服务。简化开发流程。

   单点登录平台通过提供统一的认证平台，实现单点登录。因此。应用系统并不须要开发用户认证程序。   

SSO架构及原理：

     单点登录的实质就是安全上下文（Security Context）或凭证（Credential）在多个应用系统之间的传递或共享。当用户登录系统时，client依据用户的凭证（比如username和password）为用户建立一个安全上下文，安全上下文包括用于验证用户的安全信息，系统用这个安全上下文和安全策略来推断用户是否具有訪问系统资源的权限。

单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下。用户在一处登录后。就不用在其它系统中登录，也就是用户的一次登录能得到其它全部系统的信任。

单点登录在大型站点里使用得很频繁。比如像阿里巴巴这种站点。在站点的背后是成百上千的子系统。用户一次操作或交易可能涉及到几十个子系统的协作，假设每一个子系统都须要用户认证，不仅用户会疯掉。各子系统也会为这种反复认证授权的逻辑搞疯掉。

实现单点登录说究竟就是要解决怎样产生和存储那个信任。再就是其它系统怎样验证这个信任的有效性，因此要点也就下面几个：

• 存储信任
• 验证信任
• 
  

不然发现以上的方案是把信任存储在client的Cookie里，这样的方法尽管实现方便但立刻会让人质疑两个问题：

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

• 
  

SSO的技术：

                  第一：Cookie+filter

        利用浏览同域名之间自己主动传递cookies机制。实现两个域名之间系统令牌传递问题；另外，关于跨域问题，尽管cookies本身不跨域。但能够利用它实现跨域的SSO。如：代理、暴露SSO令牌值等。

                 第二：基于CAS的sso

了解CAS工作原理后，接下来会进行单点登录的实例演示（两种）。