融云|企业通讯录的设计与实现

之前，我们已分享过【在“企业通讯录”的盲区，融云的边界与分寸】和【云办公时代，企业通讯录的技术选型】。本文将阐述企业级通讯录的设计与实现。

一、需求分析

企业通讯录需要提供的基本功能如下：

1. 支持企业按照组织架构呈树形展示。

2. 支持视图显示。支持管理员在管理后台对部门、员工信息以及组织架构进行查看和更改。

3. 支持管理人员对部门节点和员工节点的增、删、改、查操作。

4. 支持细粒度访问权限控制。对不同员工设置不同的访问权限，企业管理人员拥有所有操作权限。

5. 支持通讯录信息实时同步。员工或部门信息甚至企业架构发生变化时，需要及时通知受影响的客户端进行通讯录信息的同步。

6. 支持点击好友触发语音会议、即时消息、视频会议、企业直播等通讯业务。

7. 提供统一认证服务。用户只需登录一次，在一段时间内可以使用企业提供的其它服务。

其中，通讯录信息实时同步、细粒度访问权限控制以及统一认证服务是核心功能。

通讯录信息实时同步保证了用户本地通讯录与服务端通讯录的一致性;细粒度访问权限控制保证了用户能够获得正确的通讯录信息;统一认证服务保证了企业合法用户无需重复认证即可使用系统授权服务。

二、通讯录架构设计

基于企业通讯录功能需求，通讯录服务器架构设计如图 1，将通讯录架构层分为应用层、接口接入层、统一认证层、服务层和数据库接入层，各模块之间的通信采用消息总线的方式，即模块之间不会直接发送消息而是将消息发送到消息队列中，采用这种通信方式可以降低模块之间的耦合度，便于系统模块的扩展和维护。

图 1 - 系统架构图

三、功能与模块

业务系统功能模块

如图 2 企业通讯录服务功能模块结构图所示，客户端通过 HTTP 协议调用服务端提供的 Webservice 接口服务。

如果按照服务对象区分，可分为三类服务。

一类是为 Web 端提供服务称为 Web 端服务。

一类是为移动终端提供的服务称为移动端服务。

还有一类是整个系统的保障性服务，为 Web 端提供的服务称为基础服务。

【Web 端服务】

Web 端服务主要是管理类的，包含角色管理、权限管理、通讯录管理、日志管理、企业管理以及系统管理等。

图 2 - 功能模块结构图

√ 角色管理和权限管理模块是用来实现员工访问权限控制的

√ 通讯录管理用于增、删、改、查节点信息

√ 日志管理负责日志文件的增、查、操纵

√ 企业管理主要实现对企业的增、删、改、查操作

√ 系统管理主要实现对企业管理员的管理

【移动端服务】

为移动终端提供的主要是通讯录的获取以及更新服务。

移动终端的首次登录需要获取自己对应角色的通讯录，如果服务端通讯录信息发生变化，本地终端的通讯录需要同步更新，由通讯录同步模块实现。

【基础服务】

基础服务包括统一认证和安全模块，统一认证包括身份认证、单点登录;安全模块确保通讯录服务的数据传输安全可靠。

单点登录是指当用户请求通讯录服务时，服务端需要对请求用户的合法性进行验证，合法用户系统会提供通讯录服务，否则返回无权访问提示。用户在服务请求中会涉及到如图 3 所示认证过程。

图 3 - 权限认证流程

① 客户端向服务端发送通讯录信息同步请求

② 通讯录服务收到请求消息，会调用验证模块验证用户的合法性，即判断用户是否己登录，已登录执行步骤 ⑤，未登录执行步骤 ③

③ 如用户未登录，客户端返回身份认证页面

④ 用户在身份认证页面填写用户名、密码等相应认证信息进行验证

⑤ 如用户已登录，则根据用户角色获得访问权限

⑥ 访问 LDAP 数据库，获得通讯录信息

⑦ 服务端返回相应通讯录信息

为增加企业通讯录信息传输的安全性，客户端与服务端之间的数据传输本文采用 SSL/TLS 加密，对存储在数据库中的数据进行加密存储，以防泄露。

四、融合通信企业通讯录业务相关接口

通讯录服务需要对企业通信业务提供相对应的接口支持，还要辅助其它业务获得通信的相关信息。如图 4 所示，企业通讯录服务提供了广泛的接口支持企业通信业务和其它业务。

【I1 接口】

存在于客户端与服务端之间，主要功能如下：

√ 使用 RESTful 实现客户端对服务端的查询和更新请求

√ 采用 TLS 安全协议保证信息数据的安全传输

图 4 - 通讯录接口示意图

【I2 接口】

位于 Web 端和服务端之间，主要功能如下：

√ 通过 Web 实现对企业通讯录的增加、删除、修改、查询等操作

√ 采用 TLS 安全协议保证信息数据的安全传输

【I3 接口】

位于服务端和 IM 或语音视频之类的通讯业务之间，使通讯业务能够从通讯录服务中查找到企业或个人的相关信息以便进行通信。

【I4 接口】

位于通讯录服务和权限验证模块之间，客户端或者其他实体业务对通讯录服务的消息请求需要得到验证，合法用户才能使用通讯录业务，该接口用于提供身份验证服务。

【I5 接口】

通讯录服务和用户状态呈现之间的接口,通讯录可以通过此接口获得用户的状态信息。

【I6 接口】

位于通讯录服务和其它业务之间，主要用于向其它业务提供通讯录的查询操作。

通讯录信息模型

通讯录信息存放在 LDAP 数据库中，通讯录的各数据元描述具体见表 1。

表 1 - 数据元描述

上表所示的属性是系统默认的属性，管理员在进行员工信息操作时可根据需求进行属性的添加或删除。

目录模式(Schema)的定义

本文中的企业通讯录的数据是采用 LDAP 协议描述的，它将数据库中的数据抽象为树形结构，用户只需对这棵树的节点进行操作即可，降低了数据 操作的复杂性，真实的数据被存放到了一个关系型数据库中，本文采用的是 MySQL。

除此之外，LDAP 提供了丰富的语言接口，有利于不同终端对LDAP 的操作。Schema (模式)是 LDAP 的 一 项重要内容，它定义了数据的存储格式。

比如定义一个节点有哪些属性。本文采用的 openLDAP 中包含一些标准的 Schema， 在 openLDAP 的 Schema 文件夹下，用户也可以根据自己的需要来进行扩展，只需要在 Schema 文件夹下新建一个 Schema 文件来进行定义即可。

企业通讯录是由企业所有员工组成的联系人列表，并且与企业设置的组织架构相对应，实行层级管理。根据企业通讯录功能的需要，部门和员工以及它们的信息形成了如图 5 所示的树状结构。

图 5 - 企业通讯录组织架构图

上文给出的是本文中扩展定义的 Schema 文件，从上文看出 Schema 是由属性、 对象类、几配法则和语法四个重要元素组成。

首先给出了部门节点的属性，由部门通信地址、部门名称、部门编码以及部门员工数量组成。然后给出了员工节点的属性，有员工编号、员工姓名、性别、年龄、通信地址、手机号、SIP 号以及所属部门组成，最后给出了部门节点和员工节点的对象类型，并将属性添加到对象类型中。

基于 RBAC 模型的细粒度权限访问控制设计

细粒度是相对粗粒度而言的，细粒度权限访问控制在 RBAC(Role-Based Access Contro)模型中可理解为控制对最小权限单位客体的访问，最小权限单位客体也就是不可再分割的客体，在企业通讯录中最小权限单位是员工的个人信息如电话号码。

企业通讯录进行细粒度权限访问控制，优化了系统性能，减少系统代码量和降低系统复杂度。

在使用粗粒度的权限管理系统中，为了授权对最小权限单位的访问，不得不编写大量逻辑代码进行控制，增加了工程难度，不方便授权管理。

当然，在实际的工程中很难达到最小化分解，只能尽可能进行细粒度分解(R5)。本文通过在原有的“角色-部门-员工”权限管理模型基础上增加了“员工-信息”管理粒度使得权限得以细化，实现了最小权限访问粒度的控制。

基于角色的访问控制 RBAC 模型中包含了一些基本概念，包括用户、角色、权限、主客体、用户-角色分配(URA)、角色-权限分配(PRA)以及会话。为了介绍 RBAC 模型，这里先介绍一下这些基本概念。

主体

主动进行访问的对象，表现为系统用户或代表用户进行操作的进程。

客体

被访问的对象，是一个被动实体，表现为操作系统中的文件或目录，或者数据库的表、行、字段等，也可以是一些外设图投影仪、打印机等。

用户

访问系统数据或资源的主体，通常表现为人、系统进程或者代理等，大部分情况下指人

角色

通常指一个单位中的工作岗位，这个工作岗位具有特定权利与职责，拥有这个角色的人就具有了这种权利与职责。

权限

指被赋予了访问模式的实体，访问模式也可以说是访问权利，即有权访问哪些实体，权利包括读、写以及执行，被访问的实体与具体的应用场景有关，可以是数据库、通讯录、以及外设等。

用户-角色分配

将角色分配给用户，一个用户可以拥有多种角色，分配过后用户拥有角色相应的职责和权利。

角色-权限分配

将权限分配给角色，一个角色可以被分配多种权限，分配过后角色拥有访问系统资源的能力。

会话

指用户激活角色的过程，参与者有一个用户以及一组激活的角色。建立新会话可以激活新的角色。

在用户与权限之间引入角色中介，将用户与权限的直接关联关系弱化为间接关联关系，如图 7 所示;以角色为中间者，首先创建不同的系统资源访问权限，然后创建不同的角色，根据角色职责的不同将对应权限分配给它们，建立角色-权限的关系后，不同的角色就会有不同的访问权限。根据用户担任的岗位，将对应的角色分配给它们，建立用户-角色的关系，这就是 RBAC (基于角色的访问控制)的主要思想。

图 6 - RBAC授权示意图

RBAC 模型解耦了用户与权限之间的直接联系，通过角色与权限关联以及用户与角色关联这两部分，实现了通过角色给用户分配权限;一个用户可以有多种角色，一个角色可以有多种权限。RBAC 的这种设计，极大地方便了授权的管理。

RBAC 模型主要涉及到以下元素：

实体集

用户集 U(Users)、角色集 R(Roles)、权限集 P(Permissions)、会话集 S(Sessions)

实体关系

PA(PxR)为角色分配权限：UA(UxR)为用户分配角色;RH(RxR)为角色层次。系统管理员可根据实际系统的需求创建角色，给角色分配权限并给不同用户分配相应的角色。角色和权限之间，以及用户和角色之间都是多对多的关系，其模型图 7 所示。

RBAC 最大的特点是用户通过角色来获得访问权限，这样做增加了权限管理的灵活性，可以减少管理上的错误。

当用户在公司的职位发生变化时，只需要移去员工原来的角色并重新分配新职位对应的角色即可，避免因人员职位调动导致的重新授权。当公司的组织架构发生变化时，角色也可以根据公司新的组织架构重新设置。

除此之外，角色也可以像部门的层级关系那样具有继承关系，高级角色可以继承低级角色的访问权限。这些都是 RBAC 授权灵活性的表现，当然也降低了企业进行授权管理的成本。

图 7 - RBAC关联关系

基于“角色-部门-员工-信息”细粒度访问权限控制的信息模型设计

节点的群组化

图 8 - 节点群组化示意图

由于企业部门和员工数量很多，管理员在创建权限时不可能去设置一种角色对每一个部门以及每一个员工的访问权限，为了方便权限设置，本文将功能和职责相似的部门以及员工看作是同一类型，在创建部门和员工时系统会为它们分配固有 type 属性，具有相同的 type 类型可看成是同一群组，管理员在设置可见性时不需要去设置对每一个部门或员工的可见性，只需要设置对部门群组和员工群组的可见性即可，示例如图 8 所示。

三级权限

基于“角色-部门-员工-信息”细粒度访问控制概念，本文所提“角色-部门-员工-信息”的权限分级模型，由三级权限组成。企业通讯录由多个部门组成，每个部门下又包含多个员工，每个员工都有各种个人信息，这些具体的个人信息可认为是不可分解最小单位。

在我们的“角色-部门-员工-信息”模型中，员工的这些个人信息属于最小级别权限——三级权限，包含这些信息的个人是它们的父级权限——二级权限，包含员工的部门拥有最大权限级别——一级权限。

权限的分配

基于“角色-部门-员工-信息”细粒度访问控制概念原理，由于不同角色的用户对系统的访问权限不同。因此，用户在进入系统后，系统根据用户的 ID 查询到用户的权限集合，根据一级权限给客户端返回可见部门，根据二级权限返回可见员工，客户端收到返回信息后可生成本地通讯录的部门菜单以及各部门下所包含的员工，然后根据三级权限系统给客户端返回相应的个人信息。最后客户端将接收到的消息进行解析即可获得本地通讯录。

根据以上分析，管理员在进行访问权限管理时，首先需要设置各级权限，其次，将权限分配给角色，最后将角色分配给员工，即可完成员工对通讯录访问权限的控制。

图 9 - 权限管理模型图

通过以上分析，基于“角色-部门-员工-信息”的权限分级模型实现了权限的 细粒度访问控制，把对权限的控制最小化到了员工的具体个人信息;并根据 RBAC 的访问控制模型，得出了基手“角色-部门-员工-信息”的权限管理模型图如图 9 所示。

实体关系模型

实体关系模型基于“角色-部门-员工-信息”的分级细粒度权限控制模型，有效的实现了用户的访问权限控制，其实体关系图如图 10 所示。

图 10 - 实体关系模型

从上文的 E-R 模型图可得到几张表：

①部门表：定义部门及其属性

②用户表：定义用户及其属性

③角色表：定义角色及其属性

④一级权限表：定义对部门的访问权限

⑤二级权限表：定义对部门下员工的访问权限

⑥三级权限表：定义对员工信息的访问权限

⑦ 部门用户表：定义员工对各个部门的从属关系

⑧用户角色表：定义用户对各个角色的从属关系

⑨角色权限表：定义用户对部门、员工、个人信息的访问关系

数据库的设计

系统的部门信息、用户信息以及它们之间的从属关系，会采用 LDAP 数据库表示，在此给出的部门、员工表设计仅仅是为了阐明涉及到的实体之间的逻辑关系。

剩下的各个表采用 MySQL 存储，数据库设计如图 11 所示。

图 11 - 权限数据库设计

根据 RBAC 思想，用户、角色、权限相互独立，分别通过用户角色表和角色权限表进行关联，用户角色表中通过引用用户表中的主键用户 ID 作为外键和用户表关联，通过引用角色表中的主键角色 ID 作为外键和角色表关联;角色权限表中通过引用角色表中的主键角色 ID 作为外键和角色关联，通过引用各级权限表中的主键权限 ID 作为外键和各级权限表关联;部门和用户表中各有一个类型字段，该字段用于部门和员工的群组化管理，方便管理员的权限控制。