单点登录系统设计

 胡乱写的，俺自己都不知道对错，别当真！！！

1.     系统概述

此系统主要解决多个域名情况下，避免用户反复性登录问题。大多数企业初期不需要考虑单点登录的问题，但是随着企业逐渐发展壮大迟早会面临这个问题，作为技术负责人理当重视此事。

2.     业务对象

1. www.abc.com (产品abc)                                   rsc.abc.com(资源服务器abc)
2. www.123.com (产品123)                                   rsc.123.com(资源服务器123)
3. www.sso.com (登录服务器SSO)                        rsc.sso.com(资源服务器SSO)
4. www.jrt.com (授权服务器JRT)                           rsc.jrt.com(资源服务器JRT)
5. Token：

　　　　　　a)      SSO返回给产品的LoginToken。使用一次之后便无效。

　　　　　　b)      验证LoginToken返回给产品的ProductToken。产品与sso内部保存。

3.     产品设计

3.1.    业务分析

1. SSO登录流程：产品 --> SSO登录(SSO_Login) --> 成功 --> 得到LoginToken。
2. Token验证流程：

　　　　　　a)      产品(登录) --> 验证Token(访问SSO_CheckToken) --> 有效 --> 允许使用产品。

　　　　　　b)      产品(登录) --> 验证Token(访问SSO_CheckToken) --> 无效 --> 提示错误信息。

3.2.    标准方法

1. PRODUCT_AUTO_Logout：只允许SSO服务器调用此方法。此方法会清除用户的Session和Token。
2. PRODUCT_AUTO_AskStatus：只允许SSO服务器调用此方法。SSO服务器询问是否有效，若用户的Session有效，则回复有效，否则回复无效。

3.3.    重点提示

1. 验证Token的时候，必须带上”白名单Key(ProductKey)”，否则身份无法验证通过，程序就更不会验证Token是否有效。

4.     SSO设计

4.1.    业务分析

4.1.1.   白名单

白名单记录的是允许使用SSO作为登录系统的产品。超级管理员或程序可以通过调用标准方法：SSO_OPERATE_WhiteList读取白名单集合。

当产品拿着LoginToken来SSO验证时，SSO会先调用SSO_CheckProduct验证ProductKey是否在白名单集合里，之后再验证LoginToken的有效性。

4.1.2.   Token集合

Token集合是以用户为单位管理的。若一个用户同时登录了abc.com和123.com，那么就会有两个Token。

SSO_AUTO_CheckExpire方法检验用户Token有效期时，发现所有Token都过了有效期，SSO才会向Token对应的产品发起PRODUCT_AUTO_Logout指令。同时在SSO中销毁用户的信息。

4.2.    标准方法

1. SSO_Login：输入www.123.com，未发现有登录的痕迹，执行用户登录。
   
   
2. SSO_CheckLogin：输入www.abc.com，abc.com发现123.com已经登录过了，abc.com自动完成登录。
   
   
3. SSO_Logout：用户主动退出www.123.com，发现还有其他有效Token，则销毁自己的Token，和建立关联关系的Token。若发现其他Token全部失效，则销毁所有Token。
   
   
4. SSO_ CheckToken：用户拿着Token使用产品，产品首先调用此方法验证Token是否有效。验证时，首先判断发送请求的产品是否在“白名单集合“，然后再验证是否有效。
   
   
5. SSO_CheckProduct：检查ProductKey是否在“白名单集合“里。
   
   
6. SSO_AUTO_CheckExpire：循环检查用户Token有效期。调用SSO_AUTO_AskStatus方法执行校验。若需要注销用户，则通知所有产品Logout(调用产品的PRODUCT_AUTO_Logout方法)。
   
   
7. SSO_AUTO_AskStatus：向用户登录过的所有产品询问是否有效，若有一个产品回复有效，则将用户所有产品的Token更新为最新时间。
   
   
8. SSO_OPERATE_WhiteList：读取/刷新白名单集合。

4.3.    重点提示

由于SSO内部需要循环检查Token的有效期，服务器压力可能会比较大。可以考虑集群化方案，比如使用RSA加密Token，让Token包含管理该用户信息的服务器地址等数据，产品解密Token按照指定地址验证Token。

若采用集群化方案，登录/自动登录的功能就要改变了，它们需要询问哪台TokenServer存储着用户信息，然后处理具体业务。若询问不到结果，要以最优的方案选举一个TokenServer管理用户信息。

5.     JRT服务器

5.1.    SSO资源

1. 申请Token，向“JRT服务器“申请令牌。
2. 读取白名单集合，向“SSO资源服务器“发起请求。
3. 验证登录ID和PWD，向“Account资源服务器“发起请求。
4. 刷新Token，向“JRT服务器“发起请求。

5.2.    Product资源

1. 申请Token，向“JRT服务器“申请令牌。
2. 读取用户信息至于Session里缓存。向“Account资源服务器“发起请求。
3. 执行业务作业。向“Business资源服务器“发起请求。
4. 刷新Token，向“JRT服务器“发起请求。