企業通訊錄作為企業統一通信中其它業務功能的觸發點，需要靈活、完備的功能和好用、便捷的人機界面，以便用戶順利完成業務協作，真正為企業運轉提速，實現降本增效。
之前，我們已分享過【在“企業通訊錄”的盲區，融云的邊界與分寸】和【云辦公時代，企業通訊錄的技術選型】。本文將闡述企業級通訊錄的設計與實現。
一、需求分析
企業通訊錄需要提供的基本功能如下：
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 作為外鍵和各級權限表關聯；部門和用戶表中各有一個類型字段，該字段用于部門和員工的群組化管理，方便管理員的權限控制。
關注【融云 RongCloud】，了解更多干貨。
