【实现机制（整理抽象版）】
单点登录的机制其实是比较简单的，用一个现实中的例子做比较。颐和园是北京著名的旅游景点，也是我常去的地方。在颐和园内部有许多独立的景点，例如“苏 州街”、“佛香阁”和“德和园”，都可以在各个景点门口单独买票。很多游客需要游玩所有德景点，这种买票方式很不方便，需要在每个景点门口排队买票，钱包 拿 进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要在每个景点门 口出示一下刚才买的套票就能够被允许进入每个独立的景点。
单点登录的机制也一样，如下图所示，当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录（1）；根据用户提供的登录信 息， 认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket（2）；用户再访问别的应用的时候（3，5）就会将这个ticket 带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4，6）。如果通过效验，用户就可 以在不用再次登录的情况下访问应用系统2和应用系统3了。
集成平台SSO机制详解
当前笔者采用的集成平台单点登录的应用场景和传统企业信息集成里面的单点登录稍有不同，这里引进了三种验证措施：集成平台标识&凭证&令牌号，具体如下：
1、通过服务总线进行各第三方厂家系统的凭证校验，确认消息发送方是可信任系统；
2、通过有时效性的令牌方式进行单次登录操作校验，登录信息在校验通过后由集成平台返回；
3、第三方并不需要摒弃自身的登录功能，因为我们在单点登录的时候，通过集成平台标识来判断进行的是单点登录操作，不影响原有业务；
实现单点登录的前提是员工信息一致性，我们通过员工对照功能保证其信息的一致性。
关于员工对照使用的唯一信息，对于公司的系统，我们采用员工内部序号；而对于其他厂商的外部系统，我们提供“工作牌号”或者“工作牌号+员工姓名”的组合等方式来识别员工，通过程序去适配。
通过员工对照后，系统，科室，角色等其他信息都可以通过接口方式获取，不需要和第三方进行任何对照和关联。在实现员工对照后，其他厂商的系统即可像公司系统那样，按我们的接口文档改造后，顺利接入集成平台。
集成平台单点登录的应用场景和传统企业信息集成里面的单点登录稍有不同，平台和第三方系统的对接都是通过WS方式完成，而不是由平台直接操作子系统数据库完成；采用消息中间件的总线方式进行接口管理与操作，增强了数据准确性和流程可控性；同时引进了凭证号，令牌号和集成平台标识这三种验证机制，充分保证了系统的安全性。
单点登录流程：
1）用户登录门户，门户程序会通过服务总线遍历不同厂商的接口，采集该员工在不同子系统拥有的权限，并在SSO组件框中显示子系统列表。
2）用户若需要进入某系统，则点击相应图标，选择登录科室和角色等信息（通过接口获取），此时会在平台这边生成令牌，同时在本地打开相应业务系统，并传递令牌号和集成平台标识。
3）该业务系统识别集成平台标识后，使用令牌来调用平台的令牌验证接口，如果验证成功则利用返回的信息进行登录，错误则给予提示。
PS：上面说的流程是程序实现流程，医护人员使用流程仅仅是登录门户，单击系统直接进入即可，just so so。
关于流程，笔者画了一张简图表示，有点粗糙，凑活着看。
两种策略（单向）
1、唯一映射：两套系统用户产生一一映射关系。（携带账号密码，需同步）
2、唯一ID认证：主系统入口进入后无需再验证密码，有此ID身份即可。
3、子系统双重认证机制：用户单独账号+密码登录子系统，单点登录账号+身份认证。
