文章目录
- 背景
- 前提
- 场景一 单点登录
- 场景二 门户应用
- 场景三 类微信登录第三方登录
背景
为了解决企业内部杂乱无章，需求多变的认证问题，各系统相互孤立，用户以及部门等基础数据成为孤立数据。
场景：一个大的企业需要做信息化，慢慢迭代过程中会产生很多的应用系统，由于各种政策和人际关系原因，导致内部系统经常会有多家企业完成，例如：OA系统由A公司完成，车辆GPS跟踪系统由B公司完成，机电管理系统由C系统完成。
问题：
- 系统入口太多，10个系统要记10个网址
- 用户名/密码体系太多，10个系统10套用户名/密码
- 多个系统部门等基础数据无法互通
- 多个系统任务无法互通
前提
所有的解决方案都是以CAS为核心做的一个变种。
设计一个统一认证服务，需要接入的系统，会提前给每个系统分配appId、appsecret，用于后面的接口安全认证。第三方也可以提供一个认证成功后默认的跳转url。
appId | appsecret | url |
A_appId | A_appsecret | |
B_appId | B_appsecret |
设计了以下三种方案，供接入方根据实际情况自行选择。
涉及的角色如下：
- 认证服务管理员
- 认证服务
- 第三方系统
场景一 单点登录
单点登录（Single Sign On），简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
接入步骤如下：
步骤1：
认证服务管理员：根据第三方系统的需求，录入其appId，以及成功重定向的url，例如：http://www.xxx.com/login
步骤2:
第三方系统：在自己内部过滤器或者拦截器的鉴权处，如果鉴权不通过（鉴权自己内部的token、cookie局部会话）， 重定向到 http://sso.xx.com/sso/auth?appid=xxx&redirect=http://www.xxx.com（认证服务）
步骤3：
用户在输入正确的用户名/密码后，认证服务会重定向到之前注册的重定向url并携带ticket，例如：http://www.xxx.com/login?ticket=ceDRSfKeu
ticket | info |
ceDRSfKeu | systemA|zhangsan|createtime |
第三方系统：拿到 ticket 后，去调用认证服务校验ticket 获取账号id， http://sso.xx.com/sso/checkTicket?ticket=ceDRSfKeu
拿到账户id后，在本系统创建token、cookie等局部会话
注意：ticket是一次性的，且5分钟的有效性。
优点：
比较标准的单点登录方案。
缺点：
这种集成方式，耦合性比较强，会破坏第三方系统的认证架构，强制其走我们的统一认证服务。建议都是公司内部子系统时使用。
场景二 门户应用
用户已经登录进来，点击应用标签调转到相应第三方系统。
参考 单点登录和oauth2.0 改造了一个符合我们业务场景对接方式。
接入步骤如下：
步骤1：
认证服务管理员：根据第三方系统的需求，录入其appId，以及成功重定向的url，例如：http://www.xxx.com/portallogin
步骤2:
门户系统：用户在门户系统登录进来后，例如：点击"机电管理系统"，传递机电管理系统的appId，门户系统后台构建重定向url： http://www.xxx.com/portallogin?ticket=ceDRSfKeu，url生成的方式如下：
String redirectUrl = SsoUtil.buildRedirectUrl(userId, redirect);
步骤3：
第三方系统：拿到 ticket 后，去调用认证服务校验ticket 获取账号id， http://sso.xx.com/sso/checkTicket?ticket=ceDRSfKeu
拿到账户id后，在本系统创建token、cookie等局部会话，用户可能要做下映射
注意：ticket是一次性的，且5分钟的有效性。
优点：
接入简单，耦合性不强，对第三方的影响，仅仅是多了个入口.
缺点：
用户、部门等还是独立的需要做映射，建议对接第三方系统时使用。
场景三 类微信登录第三方登录
第三方登录，类似常见的微信登录、QQ登录等。
在登录页面放一个第三方登录：集团统一登录
步骤1：
认证服务管理员：根据第三方系统的需求，录入其appId，以及成功重定向的url，例如：http://www.xxx.com/login
步骤2:
第三方系统：在 集团统一登录 图片或者按钮的作用是 重定向到 http://sso.xx.com/sso/auth?appid=xxx&redirect=http://www.xxx.com
为了安全，参数redirect也可以不要，用一开始服务端注册的地址。
步骤3：
用户在输入用户名密码后，认证服务会重定向到之前注册的重定向url并携带ticket，例如：http://www.xxx.com/login?ticket=ceDRSfKeu
第三方系统：拿到 ticket 后，去调用认证服务校验ticket 获取账号id， http://sso.xx.com/sso/checkTicket?ticket=ceDRSfKeu
拿到账户id后，在本系统创建token、cookie等局部会话，oauth2.0是返回的access_token,后面的所有接口都是用access_token访问。
总结
场景一非常的nice和应用广泛，场景二的解决方案和场景三的解决方案都是从场景一裁剪出来的。
