关于企业应用:融云-企业通讯录的设计与实现

企业通讯录作为企业对立通信中其它业务性能的触发点，须要灵便、齐备的性能和好用、便捷的人机界面，以便用户顺利完成业务合作，真正为企业运行提速，实现降本增效。关注【融云 RongCloud】，理解协同办公平台更多干货。

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

需要剖析

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

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 作为外键和各级权限表关联；部门和用户表中各有一个类型字段，该字段用于部门和员工的群组化治理，不便管理员的权限管制。