之前，我們已分享過【在“企業(yè)通訊錄”的盲區(qū)，融云的邊界與分寸】和【云辦公時(shí)代，企業(yè)通訊錄的技術(shù)選型】。本文將闡述企業(yè)級(jí)通訊錄的設(shè)計(jì)與實(shí)現(xiàn)。

一、需求分析

企業(yè)通訊錄需要提供的基本功能如下：

1. 支持企業(yè)按照組織架構(gòu)呈樹形展示。

2. 支持視圖顯示。支持管理員在管理后臺(tái)對(duì)部門、員工信息以及組織架構(gòu)進(jìn)行查看和更改。

3. 支持管理人員對(duì)部門節(jié)點(diǎn)和員工節(jié)點(diǎn)的增、刪、改、查操作。

4. 支持細(xì)粒度訪問權(quán)限控制。對(duì)不同員工設(shè)置不同的訪問權(quán)限，企業(yè)管理人員擁有所有操作權(quán)限。

5. 支持通訊錄信息實(shí)時(shí)同步。員工或部門信息甚至企業(yè)架構(gòu)發(fā)生變化時(shí)，需要及時(shí)通知受影響的客戶端進(jìn)行通訊錄信息的同步。

6. 支持點(diǎn)擊好友觸發(fā)語音會(huì)議、即時(shí)消息、視頻會(huì)議、企業(yè)直播等通訊業(yè)務(wù)。

7. 提供統(tǒng)一認(rèn)證服務(wù)。用戶只需登錄一次，在一段時(shí)間內(nèi)可以使用企業(yè)提供的其它服務(wù)。

其中，通訊錄信息實(shí)時(shí)同步、細(xì)粒度訪問權(quán)限控制以及統(tǒng)一認(rèn)證服務(wù)是核心功能。

通訊錄信息實(shí)時(shí)同步保證了用戶本地通訊錄與服務(wù)端通訊錄的一致性;細(xì)粒度訪問權(quán)限控制保證了用戶能夠獲得正確的通訊錄信息;統(tǒng)一認(rèn)證服務(wù)保證了企業(yè)合法用戶無需重復(fù)認(rèn)證即可使用系統(tǒng)授權(quán)服務(wù)。

二、通訊錄架構(gòu)設(shè)計(jì)

基于企業(yè)通訊錄功能需求，通訊錄服務(wù)器架構(gòu)設(shè)計(jì)如圖 1，將通訊錄架構(gòu)層分為應(yīng)用層、接口接入層、統(tǒng)一認(rèn)證層、服務(wù)層和數(shù)據(jù)庫接入層，各模塊之間的通信采用消息總線的方式，即模塊之間不會(huì)直接發(fā)送消息而是將消息發(fā)送到消息隊(duì)列中，采用這種通信方式可以降低模塊之間的耦合度，便于系統(tǒng)模塊的擴(kuò)展和維護(hù)。

圖 1 - 系統(tǒng)架構(gòu)圖

三、功能與模塊

業(yè)務(wù)系統(tǒng)功能模塊

如圖 2 企業(yè)通訊錄服務(wù)功能模塊結(jié)構(gòu)圖所示，客戶端通過 HTTP 協(xié)議調(diào)用服務(wù)端提供的 Webservice 接口服務(wù)。

如果按照服務(wù)對(duì)象區(qū)分，可分為三類服務(wù)。

一類是為 Web 端提供服務(wù)稱為 Web 端服務(wù)。

一類是為移動(dòng)終端提供的服務(wù)稱為移動(dòng)端服務(wù)。

還有一類是整個(gè)系統(tǒng)的保障性服務(wù)，為 Web 端提供的服務(wù)稱為基礎(chǔ)服務(wù)。

【W(wǎng)eb 端服務(wù)】

Web 端服務(wù)主要是管理類的，包含角色管理、權(quán)限管理、通訊錄管理、日志管理、企業(yè)管理以及系統(tǒng)管理等。

圖 2 - 功能模塊結(jié)構(gòu)圖

√ 角色管理和權(quán)限管理模塊是用來實(shí)現(xiàn)員工訪問權(quán)限控制的

√ 通訊錄管理用于增、刪、改、查節(jié)點(diǎn)信息

√ 日志管理負(fù)責(zé)日志文件的增、查、操縱

√ 企業(yè)管理主要實(shí)現(xiàn)對(duì)企業(yè)的增、刪、改、查操作

√ 系統(tǒng)管理主要實(shí)現(xiàn)對(duì)企業(yè)管理員的管理

【移動(dòng)端服務(wù)】

為移動(dòng)終端提供的主要是通訊錄的獲取以及更新服務(wù)。

移動(dòng)終端的首次登錄需要獲取自己對(duì)應(yīng)角色的通訊錄，如果服務(wù)端通訊錄信息發(fā)生變化，本地終端的通訊錄需要同步更新，由通訊錄同步模塊實(shí)現(xiàn)。

【基礎(chǔ)服務(wù)】

基礎(chǔ)服務(wù)包括統(tǒng)一認(rèn)證和安全模塊，統(tǒng)一認(rèn)證包括身份認(rèn)證、單點(diǎn)登錄;安全模塊確保通訊錄服務(wù)的數(shù)據(jù)傳輸安全可靠。

單點(diǎn)登錄是指當(dāng)用戶請(qǐng)求通訊錄服務(wù)時(shí)，服務(wù)端需要對(duì)請(qǐng)求用戶的合法性進(jìn)行驗(yàn)證，合法用戶系統(tǒng)會(huì)提供通訊錄服務(wù)，否則返回?zé)o權(quán)訪問提示。用戶在服務(wù)請(qǐng)求中會(huì)涉及到如圖 3 所示認(rèn)證過程。

圖 3 - 權(quán)限認(rèn)證流程

① 客戶端向服務(wù)端發(fā)送通訊錄信息同步請(qǐng)求

② 通訊錄服務(wù)收到請(qǐng)求消息，會(huì)調(diào)用驗(yàn)證模塊驗(yàn)證用戶的合法性，即判斷用戶是否己登錄，已登錄執(zhí)行步驟 ⑤，未登錄執(zhí)行步驟 ③

③ 如用戶未登錄，客戶端返回身份認(rèn)證頁面

④ 用戶在身份認(rèn)證頁面填寫用戶名、密碼等相應(yīng)認(rèn)證信息進(jìn)行驗(yàn)證

⑤ 如用戶已登錄，則根據(jù)用戶角色獲得訪問權(quán)限

⑥ 訪問 LDAP 數(shù)據(jù)庫，獲得通訊錄信息

⑦ 服務(wù)端返回相應(yīng)通訊錄信息

為增加企業(yè)通訊錄信息傳輸?shù)陌踩�性，客戶端與服務(wù)端之間的數(shù)據(jù)傳輸本文采用 SSL/TLS 加密，對(duì)存儲(chǔ)在數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行加密存儲(chǔ)，以防泄露。

四、融合通信企業(yè)通訊錄業(yè)務(wù)相關(guān)接口

通訊錄服務(wù)需要對(duì)企業(yè)通信業(yè)務(wù)提供相對(duì)應(yīng)的接口支持，還要輔助其它業(yè)務(wù)獲得通信的相關(guān)信息。如圖 4 所示，企業(yè)通訊錄服務(wù)提供了廣泛的接口支持企業(yè)通信業(yè)務(wù)和其它業(yè)務(wù)。

【I1 接口】

存在于客戶端與服務(wù)端之間，主要功能如下：

√ 使用 RESTful 實(shí)現(xiàn)客戶端對(duì)服務(wù)端的查詢和更新請(qǐng)求

√ 采用 TLS 安全協(xié)議保證信息數(shù)據(jù)的安全傳輸

圖 4 - 通訊錄接口示意圖

【I2 接口】

位于 Web 端和服務(wù)端之間，主要功能如下：

√ 通過 Web 實(shí)現(xiàn)對(duì)企業(yè)通訊錄的增加、刪除、修改、查詢等操作

√ 采用 TLS 安全協(xié)議保證信息數(shù)據(jù)的安全傳輸

【I3 接口】

位于服務(wù)端和 IM 或語音視頻之類的通訊業(yè)務(wù)之間，使通訊業(yè)務(wù)能夠從通訊錄服務(wù)中查找到企業(yè)或個(gè)人的相關(guān)信息以便進(jìn)行通信。

【I4 接口】

位于通訊錄服務(wù)和權(quán)限驗(yàn)證模塊之間，客戶端或者其他實(shí)體業(yè)務(wù)對(duì)通訊錄服務(wù)的消息請(qǐng)求需要得到驗(yàn)證，合法用戶才能使用通訊錄業(yè)務(wù)，該接口用于提供身份驗(yàn)證服務(wù)。

【I5 接口】

通訊錄服務(wù)和用戶狀態(tài)呈現(xiàn)之間的接口,通訊錄可以通過此接口獲得用戶的狀態(tài)信息。

【I6 接口】

位于通訊錄服務(wù)和其它業(yè)務(wù)之間，主要用于向其它業(yè)務(wù)提供通訊錄的查詢操作。

通訊錄信息模型

通訊錄信息存放在 LDAP 數(shù)據(jù)庫中，通訊錄的各數(shù)據(jù)元描述具體見表 1。

表 1 - 數(shù)據(jù)元描述

上表所示的屬性是系統(tǒng)默認(rèn)的屬性，管理員在進(jìn)行員工信息操作時(shí)可根據(jù)需求進(jìn)行屬性的添加或刪除。

目錄模式(Schema)的定義

本文中的企業(yè)通訊錄的數(shù)據(jù)是采用 LDAP 協(xié)議描述的，它將數(shù)據(jù)庫中的數(shù)據(jù)抽象為樹形結(jié)構(gòu)，用戶只需對(duì)這棵樹的節(jié)點(diǎn)進(jìn)行操作即可，降低了數(shù)據(jù) 操作的復(fù)雜性，真實(shí)的數(shù)據(jù)被存放到了一個(gè)關(guān)系型數(shù)據(jù)庫中，本文采用的是 MySQL。

除此之外，LDAP 提供了豐富的語言接口，有利于不同終端對(duì)LDAP 的操作。Schema (模式)是 LDAP 的 一 項(xiàng)重要內(nèi)容，它定義了數(shù)據(jù)的存儲(chǔ)格式。

比如定義一個(gè)節(jié)點(diǎn)有哪些屬性。本文采用的 openLDAP 中包含一些標(biāo)準(zhǔn)的 Schema， 在 openLDAP 的 Schema 文件夾下，用戶也可以根據(jù)自己的需要來進(jìn)行擴(kuò)展，只需要在 Schema 文件夾下新建一個(gè) Schema 文件來進(jìn)行定義即可。

企業(yè)通訊錄是由企業(yè)所有員工組成的聯(lián)系人列表，并且與企業(yè)設(shè)置的組織架構(gòu)相對(duì)應(yīng)，實(shí)行層級(jí)管理。根據(jù)企業(yè)通訊錄功能的需要，部門和員工以及它們的信息形成了如圖 5 所示的樹狀結(jié)構(gòu)。

圖 5 - 企業(yè)通訊錄組織架構(gòu)圖

上文給出的是本文中擴(kuò)展定義的 Schema 文件，從上文看出 Schema 是由屬性、 對(duì)象類、幾配法則和語法四個(gè)重要元素組成。

首先給出了部門節(jié)點(diǎn)的屬性，由部門通信地址、部門名稱、部門編碼以及部門員工數(shù)量組成。然后給出了員工節(jié)點(diǎn)的屬性，有員工編號(hào)、員工姓名、性別、年齡、通信地址、手機(jī)號(hào)、SIP 號(hào)以及所屬部門組成，最后給出了部門節(jié)點(diǎn)和員工節(jié)點(diǎn)的對(duì)象類型，并將屬性添加到對(duì)象類型中。

基于 RBAC 模型的細(xì)粒度權(quán)限訪問控制設(shè)計(jì)

細(xì)粒度是相對(duì)粗粒度而言的，細(xì)粒度權(quán)限訪問控制在 RBAC(Role-Based Access Contro)模型中可理解為控制對(duì)最小權(quán)限單位客體的訪問，最小權(quán)限單位客體也就是不可再分割的客體，在企業(yè)通訊錄中最小權(quán)限單位是員工的個(gè)人信息如電話號(hào)碼。

企業(yè)通訊錄進(jìn)行細(xì)粒度權(quán)限訪問控制，優(yōu)化了系統(tǒng)性能，減少系統(tǒng)代碼量和降低系統(tǒng)復(fù)雜度。

在使用粗粒度的權(quán)限管理系統(tǒng)中，為了授權(quán)對(duì)最小權(quán)限單位的訪問，不得不編寫大量邏輯代碼進(jìn)行控制，增加了工程難度，不方便授權(quán)管理。

當(dāng)然，在實(shí)際的工程中很難達(dá)到最小化分解，只能盡可能進(jìn)行細(xì)粒度分解(R5)。本文通過在原有的“角色-部門-員工”權(quán)限管理模型基礎(chǔ)上增加了“員工-信息”管理粒度使得權(quán)限得以細(xì)化，實(shí)現(xiàn)了最小權(quán)限訪問粒度的控制。

基于角色的訪問控制 RBAC 模型中包含了一些基本概念，包括用戶、角色、權(quán)限、主客體、用戶-角色分配(URA)、角色-權(quán)限分配(PRA)以及會(huì)話。為了介紹 RBAC 模型，這里先介紹一下這些基本概念。

主體

主動(dòng)進(jìn)行訪問的對(duì)象，表現(xiàn)為系統(tǒng)用戶或代表用戶進(jìn)行操作的進(jìn)程。

客體

被訪問的對(duì)象，是一個(gè)被動(dòng)實(shí)體，表現(xiàn)為操作系統(tǒng)中的文件或目錄，或者數(shù)據(jù)庫的表、行、字段等，也可以是一些外設(shè)圖投影儀、打印機(jī)等。

用戶

訪問系統(tǒng)數(shù)據(jù)或資源的主體，通常表現(xiàn)為人、系統(tǒng)進(jìn)程或者代理等，大部分情況下指人

角色

通常指一個(gè)單位中的工作崗位，這個(gè)工作崗位具有特定權(quán)利與職責(zé)，擁有這個(gè)角色的人就具有了這種權(quán)利與職責(zé)。

權(quán)限

指被賦予了訪問模式的實(shí)體，訪問模式也可以說是訪問權(quán)利，即有權(quán)訪問哪些實(shí)體，權(quán)利包括讀、寫以及執(zhí)行，被訪問的實(shí)體與具體的應(yīng)用場(chǎng)景有關(guān)，可以是數(shù)據(jù)庫、通訊錄、以及外設(shè)等。

用戶-角色分配

將角色分配給用戶，一個(gè)用戶可以擁有多種角色，分配過后用戶擁有角色相應(yīng)的職責(zé)和權(quán)利。

角色-權(quán)限分配

將權(quán)限分配給角色，一個(gè)角色可以被分配多種權(quán)限，分配過后角色擁有訪問系統(tǒng)資源的能力。

會(huì)話

指用戶激活角色的過程，參與者有一個(gè)用戶以及一組激活的角色。建立新會(huì)話可以激活新的角色。

在用戶與權(quán)限之間引入角色中介，將用戶與權(quán)限的直接關(guān)聯(lián)關(guān)系弱化為間接關(guān)聯(lián)關(guān)系，如圖 7 所示;以角色為中間者，首先創(chuàng)建不同的系統(tǒng)資源訪問權(quán)限，然后創(chuàng)建不同的角色，根據(jù)角色職責(zé)的不同將對(duì)應(yīng)權(quán)限分配給它們，建立角色-權(quán)限的關(guān)系后，不同的角色就會(huì)有不同的訪問權(quán)限。根據(jù)用戶擔(dān)任的崗位，將對(duì)應(yīng)的角色分配給它們，建立用戶-角色的關(guān)系，這就是 RBAC (基于角色的訪問控制)的主要思想。

圖 6 - RBAC授權(quán)示意圖

RBAC 模型解耦了用戶與權(quán)限之間的直接聯(lián)系，通過角色與權(quán)限關(guān)聯(lián)以及用戶與角色關(guān)聯(lián)這兩部分，實(shí)現(xiàn)了通過角色給用戶分配權(quán)限;一個(gè)用戶可以有多種角色，一個(gè)角色可以有多種權(quán)限。RBAC 的這種設(shè)計(jì)，極大地方便了授權(quán)的管理。

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

實(shí)體集

用戶集 U(Users)、角色集 R(Roles)、權(quán)限集 P(Permissions)、會(huì)話集 S(Sessions)

實(shí)體關(guān)系

PA(PxR)為角色分配權(quán)限：UA(UxR)為用戶分配角色;RH(RxR)為角色層次。系統(tǒng)管理員可根據(jù)實(shí)際系統(tǒng)的需求創(chuàng)建角色，給角色分配權(quán)限并給不同用戶分配相應(yīng)的角色。角色和權(quán)限之間，以及用戶和角色之間都是多對(duì)多的關(guān)系，其模型圖 7 所示。

RBAC 最大的特點(diǎn)是用戶通過角色來獲得訪問權(quán)限，這樣做增加了權(quán)限管理的靈活性，可以減少管理上的錯(cuò)誤。

當(dāng)用戶在公司的職位發(fā)生變化時(shí)，只需要移去員工原來的角色并重新分配新職位對(duì)應(yīng)的角色即可，避免因人員職位調(diào)動(dòng)導(dǎo)致的重新授權(quán)。當(dāng)公司的組織架構(gòu)發(fā)生變化時(shí)，角色也可以根據(jù)公司新的組織架構(gòu)重新設(shè)置。

除此之外，角色也可以像部門的層級(jí)關(guān)系那樣具有繼承關(guān)系，高級(jí)角色可以繼承低級(jí)角色的訪問權(quán)限。這些都是 RBAC 授權(quán)靈活性的表現(xiàn)，當(dāng)然也降低了企業(yè)進(jìn)行授權(quán)管理的成本。

圖 7 - RBAC關(guān)聯(lián)關(guān)系

基于“角色-部門-員工-信息”細(xì)粒度訪問權(quán)限控制的信息模型設(shè)計(jì)

節(jié)點(diǎn)的群組化

圖 8 - 節(jié)點(diǎn)群組化示意圖

由于企業(yè)部門和員工數(shù)量很多，管理員在創(chuàng)建權(quán)限時(shí)不可能去設(shè)置一種角色對(duì)每一個(gè)部門以及每一個(gè)員工的訪問權(quán)限，為了方便權(quán)限設(shè)置，本文將功能和職責(zé)相似的部門以及員工看作是同一類型，在創(chuàng)建部門和員工時(shí)系統(tǒng)會(huì)為它們分配固有 type 屬性，具有相同的 type 類型可看成是同一群組，管理員在設(shè)置可見性時(shí)不需要去設(shè)置對(duì)每一個(gè)部門或員工的可見性，只需要設(shè)置對(duì)部門群組和員工群組的可見性即可，示例如圖 8 所示。

三級(jí)權(quán)限

基于“角色-部門-員工-信息”細(xì)粒度訪問控制概念，本文所提“角色-部門-員工-信息”的權(quán)限分級(jí)模型，由三級(jí)權(quán)限組成。企業(yè)通訊錄由多個(gè)部門組成，每個(gè)部門下又包含多個(gè)員工，每個(gè)員工都有各種個(gè)人信息，這些具體的個(gè)人信息可認(rèn)為是不可分解最小單位。

在我們的“角色-部門-員工-信息”模型中，員工的這些個(gè)人信息屬于最小級(jí)別權(quán)限——三級(jí)權(quán)限，包含這些信息的個(gè)人是它們的父級(jí)權(quán)限——二級(jí)權(quán)限，包含員工的部門擁有最大權(quán)限級(jí)別——一級(jí)權(quán)限。

權(quán)限的分配

基于“角色-部門-員工-信息”細(xì)粒度訪問控制概念原理，由于不同角色的用戶對(duì)系統(tǒng)的訪問權(quán)限不同。因此，用戶在進(jìn)入系統(tǒng)后，系統(tǒng)根據(jù)用戶的 ID 查詢到用戶的權(quán)限集合，根據(jù)一級(jí)權(quán)限給客戶端返回可見部門，根據(jù)二級(jí)權(quán)限返回可見員工，客戶端收到返回信息后可生成本地通訊錄的部門菜單以及各部門下所包含的員工，然后根據(jù)三級(jí)權(quán)限系統(tǒng)給客戶端返回相應(yīng)的個(gè)人信息。最后客戶端將接收到的消息進(jìn)行解析即可獲得本地通訊錄。

根據(jù)以上分析，管理員在進(jìn)行訪問權(quán)限管理時(shí)，首先需要設(shè)置各級(jí)權(quán)限，其次，將權(quán)限分配給角色，最后將角色分配給員工，即可完成員工對(duì)通訊錄訪問權(quán)限的控制。

圖 9 - 權(quán)限管理模型圖

通過以上分析，基于“角色-部門-員工-信息”的權(quán)限分級(jí)模型實(shí)現(xiàn)了權(quán)限的 細(xì)粒度訪問控制，把對(duì)權(quán)限的控制最小化到了員工的具體個(gè)人信息;并根據(jù) RBAC 的訪問控制模型，得出了基手“角色-部門-員工-信息”的權(quán)限管理模型圖如圖 9 所示。

實(shí)體關(guān)系模型

實(shí)體關(guān)系模型基于“角色-部門-員工-信息”的分級(jí)細(xì)粒度權(quán)限控制模型，有效的實(shí)現(xiàn)了用戶的訪問權(quán)限控制，其實(shí)體關(guān)系圖如圖 10 所示。

圖 10 - 實(shí)體關(guān)系模型

從上文的 E-R 模型圖可得到幾張表：

①部門表：定義部門及其屬性

②用戶表：定義用戶及其屬性

③角色表：定義角色及其屬性

④一級(jí)權(quán)限表：定義對(duì)部門的訪問權(quán)限

⑤二級(jí)權(quán)限表：定義對(duì)部門下員工的訪問權(quán)限

⑥三級(jí)權(quán)限表：定義對(duì)員工信息的訪問權(quán)限

⑦ 部門用戶表：定義員工對(duì)各個(gè)部門的從屬關(guān)系

⑧用戶角色表：定義用戶對(duì)各個(gè)角色的從屬關(guān)系

⑨角色權(quán)限表：定義用戶對(duì)部門、員工、個(gè)人信息的訪問關(guān)系

數(shù)據(jù)庫的設(shè)計(jì)

系統(tǒng)的部門信息、用戶信息以及它們之間的從屬關(guān)系，會(huì)采用 LDAP 數(shù)據(jù)庫表示，在此給出的部門、員工表設(shè)計(jì)僅僅是為了闡明涉及到的實(shí)體之間的邏輯關(guān)系。

剩下的各個(gè)表采用 MySQL 存儲(chǔ)，數(shù)據(jù)庫設(shè)計(jì)如圖 11 所示。

圖 11 - 權(quán)限數(shù)據(jù)庫設(shè)計(jì)

根據(jù) RBAC 思想，用戶、角色、權(quán)限相互獨(dú)立，分別通過用戶角色表和角色權(quán)限表進(jìn)行關(guān)聯(lián)，用戶角色表中通過引用用戶表中的主鍵用戶 ID 作為外鍵和用戶表關(guān)聯(lián)，通過引用角色表中的主鍵角色 ID 作為外鍵和角色表關(guān)聯(lián);角色權(quán)限表中通過引用角色表中的主鍵角色 ID 作為外鍵和角色關(guān)聯(lián)，通過引用各級(jí)權(quán)限表中的主鍵權(quán)限 ID 作為外鍵和各級(jí)權(quán)限表關(guān)聯(lián);部門和用戶表中各有一個(gè)類型字段，該字段用于部門和員工的群組化管理，方便管理員的權(quán)限控制。