《浅谈架构之路：单点登陆 SSO》

前言：SSO 单点登陆

　　“半吊子”的全栈工程师又来了，技术类的文章才发表了两篇，原本想先将主攻的几个系列都开个头（Nodejs、Java、前端、架构、全栈等等），无奈博客起步太晚，写博文的时间又没有不少，只好不按顺序乱发一通，请你们见谅。

　　本篇文章介绍一下单点登陆，不像上一篇博文介绍的先后端分离，SSO 并不能算是一种架构吧，只能说是一个解决方案。因为笔者参与过医院集成平台项目，负责其中单点登陆的设计研发工做，将经验总结分享一下，也不必定是最优方案，正确与否那就“仁者见仁智者见智”了。

　　单点登陆（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只须要登陆一次就能够访问全部相互信任的应用系统，即用户只须要记住一组用户名和密码就能够登陆全部有权限的系统。

　　文章导读：开篇先介绍一下笔者从事医疗行业出现单点登陆的项目需求，毕竟是需求驱动研发；再将整理的通用版的单点登陆知识进行分享；接着介绍一下笔者当前采用集成平台单点登陆方案，最后是一些相关扩展。

单点登陆背景介绍

　　【医疗行业的需求】　　

　　随着医院信息化建设的深刻，信息化系统愈来愈多，五花八门多种多样，初步统计目前医院信息化子系统数量已经多达几十个。这些系统的安装维护不只让信息中心花费大量心血，也让多角色的用户在使用系统时头疼不已。他们在使用系统前首先要寻找系统图标，要记住登陆各个系统的用户与密码进行登陆验证。找图标、记帐户、记密码、这些运用步骤已经让用户以为医院信息化给他们带来必定的负担。

        这时候单点登陆就应运而生，他能让用户在运用系统时能准确的寻找到他们须要运用的系统图标，方便他们在安全验证；只须要记住一个密码就能够实现全部有权限运用子系统的登陆验证；用户只须要登陆一次就能够访问全部相互信任的应用系统，即用户只须要记住一组用户名和密码就能够登陆全部有权限的系统。

 

　　【企业内部的需求】　　　

　　较大的企业内部，通常都有不少的业务支持系统为其提供相应的管理和IT服务。这些不一样的系统每每是在不一样的时期建设起来的，运行在不一样的平台上；也许是由不一样厂商开发，使用了各类不一样的技术和标准。为了下降管理的消耗，最大限度的重用已有投资的系统，不少企业都在进行着企业应用集成（EAI）。企业应用集成能够在不一样层面上进行：例如在数据存储层面 上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。事实上，还用一个层面 上的集成变得愈来愈重要，那就是“身份认证”的整合，也就是“单点登陆”。

　　一般来讲，每一个单独的系统都会有本身的安全体系和身份认证系统。整合之前，进入每一个系统都须要进行登陆，这样的局面不只给管理上带来了很大的困难，在安全方面也埋下了重大的隐患。使用“单点登陆”整合后，只须要登陆一次就能够进入多个系统，而不须要从新登陆，这不只仅带来了更好的用户体验，更重要的是下降了安全的风险和管理的消耗。

　　另外，使用“单点登陆”仍是SOA时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通信大量存在，服务之间的安全认证是SOA应用的难点之一，应此创建“单点登陆”的系统体系可以大大简化SOA的安全问题，提升服务之间的合做效率。

 

　　【实现机制（整理抽象版）】

       单点登陆的机制实际上是比较简单的，用一个现实中的例子作比较。颐和园是北京著名的旅游景点，也是我常去的地方。在颐和园内部有许多独立的景点，例如“苏州街”、“佛香阁”和“德和园”，均可以在各个景点门口单独买票。不少游客须要游玩全部德景点，这种买票方式很不方便，须要在每一个景点门口排队买票，钱包拿 进拿出的，容易丢失，很不安全。因而绝大多数游客选择在大门口买一张通票（也叫套票），就能够玩遍全部的景点而不须要从新再买票。他们只须要在每一个景点门 口出示一下刚才买的套票就可以被容许进入每一个独立的景点。

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

 

集成平台SSO机制详解

　　【验证机制】

　　当前笔者采用的集成平台单点登陆的应用场景和传统企业信息集成里面的单点登陆稍有不一样，这里引进了三种验证措施：集成平台标识&凭证&令牌号，具体以下：

　　一、经过服务总线进行各第三方厂家系统的凭证校验，确认消息发送方是可信任系统；

　　二、经过有时效性的令牌方式进行单次登陆操做校验，登陆信息在校验经过后由集成平台返回；

　　三、第三方并不须要摒弃自身的登陆功能，由于咱们在单点登陆的时候，经过集成平台标识来判断进行的是单点登陆操做，不影响原有业务；

 

　　【用户一致性】

       实现单点登陆的前提是员工信息一致性，咱们经过员工对照功能保证其信息的一致性。

       关于员工对照使用的惟一信息，对于公司的系统，咱们采用员工内部序号；而对于其余厂商的外部系统，咱们提供“工做牌号”或者“工做牌号+员工姓名”的组合等方式来识别员工，经过程序去适配。

       经过员工对照后，系统，科室，角色等其余信息均可以经过接口方式获取，不须要和第三方进行任何对照和关联。在实现员工对照后，其余厂商的系统便可像公司系统那样，按咱们的接口文档改造后，顺利接入集成平台。

 

　　【界面展现】

　　集成平台的SSO集成在统一工做门户上，做为一个组件展现，医护人员只须要登陆门户，就能够方便的进入全部平常须要使用到的医疗系统。

 

　　【实现机制与流程】

　　集成平台单点登陆的应用场景和传统企业信息集成里面的单点登陆稍有不一样，平台和第三方系统的对接都是经过WS方式完成，而不是由平台直接操做子系统数据库完成；采用消息中间件的总线方式进行接口管理与操做，加强了数据准确性和流程可控性；同时引进了凭证号，令牌号和集成平台标识这三种验证机制，充分保证了系统的安全性。

　　单点登陆流程： 

　　1）用户登陆门户，门户程序会经过服务总线遍历不一样厂商的接口，采集该员工在不一样子系统拥有的权限，并在SSO组件框中显示子系统列表。

　　2）用户若须要进入某系统，则点击相应图标，选择登陆科室和角色等信息（经过接口获取），此时会在平台这边生成令牌，同时在本地打开相应业务系统，并传递令牌号和集成平台标识。

　　3）该业务系统识别集成平台标识后，使用令牌来调用平台的令牌验证接口，若是验证成功则利用返回的信息进行登陆，错误则给予提示。

　　PS：上面说的流程是程序实现流程，医护人员使用流程仅仅是登陆门户，单击系统直接进入便可，just so so。

　　关于流程，笔者画了一张简图表示，有点粗糙，凑活着看。

　　

 

扩展：为什么采用这种实现方式？

　　为何不采用目前流行的Active Directory或者CAS方式实现单点登陆？

　　关于这点，主要出于下面两点考虑：

        a）鉴于医院集成平台单点登陆的特殊性（同时要对接BS和CS系统），纯web的cookie和session以及CAS等方式不适用。

        b）集成平台SSO建设在服务总线基础之上，借助消息中间件，进行全部第三方系统的接口管理，使用令牌和凭证来保证对接及时安全性，同时经过员工主索引的也实现了医院员工统一管理和惟一性确认，在集成平台这样的大背景下，咱们为什么还要选择须要额外用户权限配置的Active Directory方式呢？

扩展：统一受权机制

　　嗯，这里为何忽然提到统一受权，这边不是单点登陆专题吗？

　　其实，在实现了单点登陆解决方案后，特别是在保证员工一致性、和不一样第三方之间系统交互模式建设后，为统一受权也提供了实现方案。

　　简单介绍一下统一受权的背景：因为全院信息化产品很是丰富，每一个独立厂商产品都有独立的系统受权方式。没法给员工统一受权让客户的管理工做人员十分苦恼。若是咱们能够将第三方和本公司的产品全部权限都收集到集成平台中进行统一受权，那将大大增长了咱们全院信息化的统一性，同时大幅减轻咱们客户管理人员的工做压力。

　　受权内容：受权登陆科室，受权使用系统，受权使用系统菜单，受权报表权限，受权一些特定业务权限。

　　所以，单点登陆系统同时集成了统一受权的功能，为不一样系统提供代理受权功能，能够直接在单点登陆上为不一样系统进行角色员工权限分发等工做。

　　PS：整合了统一受权后，单点登陆有了高大上的新名字，“统一登陆平台”，囧。。。

　　PS_2：因为这不是统一受权专场，这边不过多介绍，有时间会再开相应博文。

编后语

      单点登陆介绍差很少了，每一个人对单点登陆的理解和实现都各不相同，正所谓：“横当作岭侧成峰，远近高低各不一样”。

　　咱们不用去在乎这些，抛开实现，其实最重要的仍是掌握单点登陆的这种思路，并用来解决实际生产生活中的适用的问题。