技术干货 | 统一认证系统的高可用与业务系统的应急码设计

通过建设一套统一身份认证的系统，将用户的登录入口进行统一。企业用户只需要知道一个地址，一套用户名口令，进行一次认证，即可实现所有应用集中访问，可大大的提升用户的使用体验。

那么我们回过头来想一想，既然用户的访问入口进行了统一，那么从架构上来看，要是这个统一的入口白旗高高挂起、歇菜了，那岂不是所有的用户都访问不了？

上述统一认证系统的故障场景，也正是在前期技术方案交流过程中，大多数客户都在问的问题：

1、统一身份认证系统本身架构如何设计，以保障统一入口的高可用？

2、当系统短时间内无法访问的情况下，关键业务系统如何保障业务访问的连续性？

本篇文章专门针对客户提出的两个问题，从系统本身以及业务系统层面两个不同的角度对上述问题进行分析解答。

首先，针对统一认证系统的高可用架构设计，我们主要介绍三种方案：

传统高可用架构

高可用架构设计-示意图

传统高可用架构设计，主要从三个方面解决统一身份认证系统的高可用问题：

● 应用服务集群部署架构：

统一身份认证系统作为用户的统一且唯一的认证入口，同时还会承担所有用户的大量的请求。为解决应用服务器的单点故障问题，我们可以通过增加应用服务器，进行集群部署。同时，多台服务器同时提供服务，可以降低单台应用服务器所承受的服务压力，提高系统的服务性能，提升用户的访问速度。

应用服务器前面部署负载均衡服务器调度用户请求，根据分发策略将请求分发到多个应用服务器节点。

当系统的性能达到瓶颈时，也可以采用横向扩展应用服务器的方式进行性能扩容。

小知识：

常用的负载均衡的选择上，通常有硬件及软件两种方案：

? 硬件方案，价格比较昂贵，通常有F5、Redware等硬件产品；

? 软件方案，通常使用LVS（Linux Virtual Server）、HAProxy、Nginx等方式，其中LVS工作于四层网络，HAProxy可工作于四层及七层网络，Nginx工作于七层网络，最新版的Nginx（1.9版本后）加入了四层网络的支持；

● 负载均衡HA部署架构：

从以上应用服务集群部署架构上来看，虽然统一认证应用服务已实现了集群部署，多台服务器提供服务避免了单点故障的问题。但是负载均衡服务同样面临着单点故障的问题，如负载均衡服务出现问题，所有用户依然无法正常访问。

所以，对负载均衡设备进行HA高可用部署，同样显得很有必要：

通过将负载均衡服务进行HA高可用部署，当当前提供服务的负载均衡服务出现故障时，可自动将服务切换到热备的均衡负载设备上，保障系统不间断的提供服务。

● 数据服务集群部署架构：

统一身份认证系统的数据库，这也是必须需要解决且最为关键的一环，对数据库服务进行集群部署，即可解决数据服务单点故障的问题。

在数据库的集群部署上，根据不同的数据库产品，同样有着不同的集群技术方案，以下列举以下主流的几种数据库的集群方案：

■ Oracle数据库：采用共享存储实现RAC集群方案，数据存放在一个共享存储中，多个数据节点同时操作数据；

■ MySQL数据库：可采用主主复制、主备复制模式，数据放在各自服务器上，通过配置的主主复制、主备复制模式实现数据文件的同步；

■ DB2数据库：可提供HADR、pureScale等部署技术，其中HADR技术为双活节点的部署模式，通过数据库日志复制的方式实现节点间的数据同步，pureScale技术则为多服务节点+共享存储的部署模式；

上述传统架构设计，企业可以通过横向扩展的方式进行性能扩容，可以满足大多数企业的统一身份认证系统建设需要。

微服务部署架构

从架构上来看，上述设计是基于传统的部署方案进行架构设计。当需要对统一身份进行版本发布时，往往是动一发牵全身，每次发布都需要需要发布的时间窗口，并提前对用户进行通知。

这个问题可通过最新的微服务架构得到缓解：

首先，通过对统一身份认证的服务模块分拆为不同的微服务，包括：

? SSO模块：提供统一认证服务

? Selfcare模块：提供用户自助服务

? IDM模块：提供身份管理服务

? Audit模块：提供安全审计服务

? Admin Console模块：提供后台管理服务

同时，后端的身份认证服务，通过API网关对外发布，并在API网关上实现身份认证服务相关API的权限管控，保证系统安全性。

异地灾备部署架构

前面介绍的高可用部署架构，足以满足中小企业对统一身份认证系统建设的需要。

但针对规模较大的集团类型企业，需要考虑建设异地灾备中心的部署架构，以保障切换到灾备中心时业务访问的连续性。

异地灾备部署架构-示意图

我们建议异地灾备中心部署同等架构的统一身份认证系统，底层数据服务采用以下同步机制：

? Oracle数据库：采用共享存储实现RAC集群方案，数据存放在一个共享存储中，多个数据节点同时操作数据；

? MySQL数据库：可采用主主复制、主备复制模式，数据放在各自服务器上，通过配置的主主复制、主备复制模式实现数据文件的同步；

? DB2数据库：可提供HADR、pureScale等部署技术，其中HADR技术为双活节点的部署模式，通过数据库日志复制的方式实现节点间的数据同步；

接下来，我们来介绍为什么关键业务系统要做应急逃生设计，以及如何做应急逃生？

为什么要做应急逃生设计？

统一身份认证系统通过上述高可用架构设计，已实现系统本身架构设计层面的冗余备份，在非极端情况下足以保障业务系统访问的连续性。

那为什么业务系统还要做应急逃生设计呢？

应急逃生，顾名思义，就是要解决统一身份认证系统不可用的情况，用户能够绕过统一身份认证系统不间断访问业务。

应急逃生设计的初衷主要是两个原因：

一是为满足特定行业，特定场景下的关键业务系统连续访问的要求，比如银行、机场、证券等行业生产类的核心业务系统；

二是从源头上解决用户统一访问入口前，业务系统最关注的核心诉求：业务系统如何切换回原登录认证入口进行认证；

如何做应急逃生设计？

统一身份认证系统要实现关键业务系统的应急逃生，需要从总体设计方案上实现以下要素：

? 业务系统切换回原登录入口，用户使用什么样的密码进行认证？

? 用户切换回本地认证时，原系统用户的应急逃生密码是否需要集中管理？

? 统一身份认证系统的认证体系，是否需要和业务系统的本地认证体系脱钩？

? 在应急逃生方案设计时，如何保障统一身份认证系统本身密码的安全性？

针对上述应急逃生设计需求的关注要素，我们引入业务系统“应急码”的设计理念，通过集中管控业务系统应急码的模式，来解决业务系统最为关注的核心诉求-应急逃生。

●“应急码”的概念定义：

业务系统切换回本地认证入口时，用户登录原入口认证时可以使用的登录密码；

● 如何生成 & 如何通知 “应急码”：

前提：统一身份认证系统已经集中管理关键业务系统的访问权限；

统一身份管理模块-示意图

1. 当用户申请开通业务系统的访问权限时，由统一身份认证系统为业务系统生成独立的“应急码”；

其中，应急码由独立的密码策略生成，以区分于现有账号密码生成机制，以保障统一身份认证系统的安全性。

2. 当业务系统权限成功开通后，通过邮件或者短信通知的机制，告知用户该业务系统的“应急码”，以确保应急码可以通知到最终用户。

备注：

当用户申请多个业务系统权限时，上述应急码生成与通知机制就可以保障各个业务系统应急码的不同，间接保障各自关键业务系统的安全性。

● 用户如何使用“应急码”：

应急逃生场景-示意图

逃生切换前提：

IAM系统出现不能访问情况，短时间内无法恢复统一认证服务；

应急码如何使用：

a) 业务管理员手动切换回本地紧急认证模式，为用户登录提供应急认证服务；

b) 用户需要使用应用账号和应急登录码进行登录认证；

c) 业务系统认证成功后，用户可以正常使用业务系统；