统一身份认证是何做好统整个 IT 架构的最基本的组成部分 ，而账号则是身份实现统一身份认证的基础 
。做好账号的认证规划和设计直接决定着企业整个信息系统建设的便利与难易程度，决定着能否敏捷和快速赋能，账号决定着数字化转型的管理投入和效率。

用户账号是及集用户身份的一种表示 。传统统一身份认证系统往往作为外围系统来集成各个应用系统 ，源码下载何做好统而不是身份作为核心基础系统被其他应用系统来集成 。所以传统统一身份认证系统的认证建设存在众多的问题，使设计实现复杂化 ，账号管理复杂化，管理集成复杂化。及集

我们今天将详细讨论下统一身份认证账号设计的何做好统几个相关问题：

1. 账号基础数据来源及管理

账号( Account )是统一身份认证系统中 4A 管理中的一个要素。账号数据来源于哪里是身份建设统一身份认证平台时首先要确认的问题。账号通常可以简单分为内部员工账号和外部客户 / 用户账号 。香港云服务器认证内部账号也可能包括工勤账号 、外包账号 、合作伙伴账号等。外部客户 / 用户账号则通常是业务客户或用户的账号。内部和外部账号通常是两个领域的账号管理需求 ，需要分别进行处理 。因此统一身份认证平台需要支持“多租户”能力，以区分不同领域账号管理或安全隔离要求
。

内部账号通常可以基于公司的 AD 或人力资源系统账号为基础，构建统一账号管理能力
。外部账号则可以基于 CRM 系统账号为基础构建外部用户统一账号认证管理能力。建站模板在统一身份认证平台内，表示用户身份的账号一定是唯一的。公司内部账号往往是基于 AD 或 LDAP 的 ，统一身份认证平台的账号体系一旦建立起来 ，就可以替换掉 AD 或 LDAP ，不用再去集成 AD 或 LDAP 。身份认证账号一定是处于最底层的，其他系统都要基于账号体系来构建登录认证的云计算。

由于系统建设不可能一步到位，所以可能存在很多系统还是基于 AD 或 LDAP 进行账号管理的，这就需要统一身份认证平台提供临时中间层，支持 LDAP 集成接口 ，以替换那些用到 AD 或 LDAP 的系统的配置。

账号和用户是两个独立的对象。账号在统一身份认证平台来维护，而用户则往往在人力资源管理系统维护。在统一身份认证平台内部 ，源码库账号可以关联多种身份标识，以支持不同的认证方式或多因子认证 。而人力资源管理系统等应用系统 ，则按照系统集成统一身份认证平台的方式来实现。

2. 用户管理

账号管理可以很简单，不包含用户其他信息 ，只代表某个用户的身份 。就像人的身份证号一样。不过用户的信息通常是很多的 ，高防服务器比如姓名 、年龄等基本信息
，还有教育背景、工作经历、社会关系、培训经历、荣誉证书等信息。这些信息通常在人力资源系统里面进行维护管理。

从平台融合微服务架构设计来说，统一身份认证平台可以不需要考虑用户信息的管理和维护。用户管理可以单独成为一个独立的组件模块或微服务组件
，可以放在人力资源系统、 CRM 系统等来维护。通过用户账号和用户信息关联起来，先在统一身份认证平台创建账号，然后其他应用使用这个账号进行数据结构、数据表设计和实现管理 。

所有的用户在统一身份认证平台首先要根据规则生成账号，比如员工账号 、外包账号、供应商账号等，然后账号作为外键来关联用户其他相关信息。

(1) 账号、用户和用户身份标识

用户管理一定要首先为用户创建账号。存量系统中用户都有账号 /ID 标识
 ，但由于每个系统每个应用都是一套独立的账号体系 ，形成数据孤岛，带来众多的数据治理和数据使用问题，因此  ，通过构建统一的账号体系来解决这些问题，减少重复建设
，提升数字化效率。为用户创建账号后并为用户绑定该账号，则用户就可以使用该账号来标识自己的身份。账号是用户身份的一种标识 。在统一身份认证平台中
，还会存储其它用户身份标识 ，比如人脸识别图像信息用于人脸识别认证 ，指纹信息用于指纹认证，虹膜信息用于虹膜认证，手机号用于短信验证码认证等 。这些身份标识都可以唯一标识一个用户
。

(2) 账号和身份绑定

账号可以是独立的
，用户是独立的对象，但用户身份是和用户相关联的。首先要把账号分配给用户，然后采集用户身份标识信息，比如指纹、人脸 、手机号等，把账号和用户身份标识对应起来 ，从而提供了统一的身份认证能力。用户可以选择登录认证方式来认证登录
。

3. 应用系统账号集成

每个应用系统几乎都有一套自己的账号、权限体系。而且 IT 这么多年的建设，每家公司都有大大小小几十套上百套系统
。所以账号、权限
、日志等可能就重复建设了几十次上百次 
。要建设统一身份认证体系，不得不集成这些大大小小的系统 。那么该怎么集成?

我了解到的几乎都是把数据复制一份导入到统一认证平台  。可能大家都习惯了数据导来导去，但这是我最反对的 ，最深恶痛绝的。那么多数据孤岛、数据不一致、数据混乱等问题就是这样造成的
。很多人往往为了一时的便利根本不考虑其他，后期你不得不付出数倍数十倍的代价来解决这个问题。就像说句谎言
，你不得不用十句百句来圆谎。

在讨论正确的处理方法之前，我们需要明确在建设统一身份认证平台时权限分层的问题 。认识并理解用户访问权限的层级是认证体系建设的关键之一。

(1) 权限分层

首先统一身份认证平台用户登录后，看到的是他能访问的应用系统列表，比如一个人可以访问 OA  、 CRM  ，另外一个人可以访问 OA 、 HR 系统 
。这是第一层的权限访问控制。

其次，用户进入特定的应用系统之后，有操作不同应用功能的权限。比如一个人能访问 OA 系统的报表功能 ，另外一个人可以访问 OA 系统除报表外的其他功能。不同的人在某个应用系统中的角色是不一样的，角色对应的权限也就不一样了。

(2) 新上线应用

对于新研发上线的应用，在研发之初就要使用统一身份认证平台的账号和权限体系  ，通过统一身份认证平台提供的标准化接口来集成。这样，所有的应用最终将融合为一个系统，每个应用相当于一个当前系统的一个组件模块。

(3) 存量应用系统

统一身份认证平台的账号首先解决的是用户登录认证的问题 。登录之后访问存量系统时，由于账号可能存在不一致
，这就需要在统一身份认证平台内支持账号映射能力 ，自动转换为可访问系统的内部账号
。这样不用更改存量系统 ，只实现统一身份认证和单点登录能力 。

4. 账号管理问题

在建设统一身份认证平台时  ，我们不得不面对公共账号 、多账号
、账号委托等问题。比如邮件系统的公共账号
、多账号问题 ，业务系统的账号委托问题等 ，这些问题都可以结合授权机制来处理 。

(1) 账号委托问题处理

在传统的应用系统中经常会遇到账号委托的问题，从身份认证和审计的角度来说是不合理的 。账号委托是把账号直接赋予某个人来使用这个账号 ，就像我可以拿着你的身份证去办理一些事情，是以你的身份来办理的，所以可能其他人并不知道是我操作的 ，从审计角度来说，就是你的行为  ，而不是我的行为。所以这是有问题的 。

正确的做法是通过授权管理机制来实现。你可以把你的权限授权给我 ，我就有权限操作你能操作的业务功能
。从审计角度来看，这是我的行为，也可以看到你授权给我了，所以我能代表你来做这些业务，如果有什么意外或不正确，可以通过审计记录很容易定位到操作人 。

功能实现并不难，难在思想和思维。一说要改变这些不正确的设计
，很多人就会有很多藉口，要么推托业务要求，要么推托改起来太复杂等等
，其实也就是不愿意改 ，怕改出问题。这样就要求在数字化转型提升应用效率的时候需要有全局规划、顶层设计，通过开发人员自觉来完善几乎是不可能的。

(2) 公共账号问题

邮件系统等会涉及群组账号 ，比如以某个部门或者团队来发布通知  。但必须明白，公共账号是不可以通过统一身份认证来登录的 。公共账号只和某个应用系统相关，是特定的需求 ，有特定的适用范围
 ，超过了这个范围就是无效的 。

因此公共账号在统一认证平台是不保存的。如果某些应用用到公共账号
，则可以在这些应用中来创建和维护 ，作为某个人的附属账号通过授权机制来进行管理和维护 。也就是公共账号可以在这个应用系统内部授权给某个人来使用，一旦超出了这个应用系统范围则是无效的;同时也可以在需要的时候回收权限。

(3) 多账号问题

既然有公共账号，难免就需要有人来维护或代表这些公共账号处理一些事情。但就像前面我们讨论的公共账号问题，一定是有范围限定的 。在统一身份认证平台内，一个用户的账号是唯一的 。只有具体到某个应用系统内，才会有多账号问题 ，多账号也就只限定在这个应用系统内。在统一身份认证平台内部账号映射管理时 ，可为该应用系统映射多个“内部账号”(或可称为“二级账号”)，用户访问该应用系统时则可选择用哪个“内部账号”登录。

5. 管理账号/运维账号问题

应用初始管理账号和运维账号也是需要考虑的。通常我们设置应用系统初始 admin 账号，用 admin 来初始化应用系统。一旦通过角色权限设置管理员用户
， admin 账号就需要被停用 。在统一身份认证平台
，是不能映射用户到应用 admin 账号的， Admin 只是做初始化 。后期的管理和运维都要用统一身份认证平台的账号，对应到具体的有身份的人。这样才符合认证审计的要求
。

很多人不理解建设统一身份认证平台的初衷 ，仅仅把它当作一个系统实现单点登录、双因子认证等，更没有认真考虑账号管理等问题，而忽略了其潜在的价值。就像我们前面提到的，统一身份认证平台是实现平台融合的最基础组件 ，只有设计好整个账号体系 ，才能为后续的应用建设带来敏捷和效率。