企業(yè)通訊錄作為企業(yè)統(tǒng)一通信中其它業(yè)務(wù)功能的觸發(fā)點，需要靈活、完備的功能和好用、便捷的人機界面，以便用戶順利完成業(yè)務(wù)協(xié)作，真正為企業(yè)運轉(zhuǎn)提速，實現(xiàn)降本增效。
之前，我們已分享過【在“企業(yè)通訊錄”的盲區(qū)，融云的邊界與分寸】和【云辦公時代，企業(yè)通訊錄的技術(shù)選型】。本文將闡述企業(yè)級通訊錄的設(shè)計與實現(xiàn)。
一、需求分析
企業(yè)通訊錄需要提供的基本功能如下：
1. 支持企業(yè)按照組織架構(gòu)呈樹形展示。
2. 支持視圖顯示。支持管理員在管理后臺對部門、員工信息以及組織架構(gòu)進行查看和更改。
3. 支持管理人員對部門節(jié)點和員工節(jié)點的增、刪、改、查操作。
4. 支持細粒度訪問權(quán)限控制。對不同員工設(shè)置不同的訪問權(quán)限，企業(yè)管理人員擁有所有操作權(quán)限。
5. 支持通訊錄信息實時同步。員工或部門信息甚至企業(yè)架構(gòu)發(fā)生變化時，需要及時通知受影響的客戶端進行通訊錄信息的同步。
6. 支持點擊好友觸發(fā)語音會議、即時消息、視頻會議、企業(yè)直播等通訊業(yè)務(wù)。
7. 提供統(tǒng)一認證服務(wù)。用戶只需登錄一次，在一段時間內(nèi)可以使用企業(yè)提供的其它服務(wù)。
其中，通訊錄信息實時同步、細粒度訪問權(quán)限控制以及統(tǒng)一認證服務(wù)是核心功能。
通訊錄信息實時同步保證了用戶本地通訊錄與服務(wù)端通訊錄的一致性;細粒度訪問權(quán)限控制保證了用戶能夠獲得正確的通訊錄信息;統(tǒng)一認證服務(wù)保證了企業(yè)合法用戶無需重復(fù)認證即可使用系統(tǒng)授權(quán)服務(wù)。
二、通訊錄架構(gòu)設(shè)計
基于企業(yè)通訊錄功能需求，通訊錄服務(wù)器架構(gòu)設(shè)計如圖1，將通訊錄架構(gòu)層分為應(yīng)用層、接口接入層、統(tǒng)一認證層、服務(wù)層和數(shù)據(jù)庫接入層，各模塊之間的通信采用消息總線的方式，即模塊之間不會直接發(fā)送消息而是將消息發(fā)送到消息隊列中，采用這種通信方式可以降低模塊之間的耦合度，便于系統(tǒng)模塊的擴展和維護。
圖1 - 系統(tǒng)架構(gòu)圖
三、功能與模塊
業(yè)務(wù)系統(tǒng)功能模塊
如圖2 企業(yè)通訊錄服務(wù)功能模塊結(jié)構(gòu)圖所示，客戶端通過 HTTP 協(xié)議調(diào)用服務(wù)端提供的 Webservice 接口服務(wù)。
如果按照服務(wù)對象區(qū)分，可分為三類服務(wù)。
一類是為Web 端提供服務(wù)稱為 Web 端服務(wù)。
一類是為移動終端提供的服務(wù)稱為移動端服務(wù)。
還有一類是整個系統(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)限管理模塊是用來實現(xiàn)員工訪問權(quán)限控制的
√ 通訊錄管理用于增、刪、改、查節(jié)點信息
√ 日志管理負責(zé)日志文件的增、查、操縱
√ 企業(yè)管理主要實現(xiàn)對企業(yè)的增、刪、改、查操作
√ 系統(tǒng)管理主要實現(xiàn)對企業(yè)管理員的管理
【移動端服務(wù)】
為移動終端提供的主要是通訊錄的獲取以及更新服務(wù)。
移動終端的首次登錄需要獲取自己對應(yīng)角色的通訊錄，如果服務(wù)端通訊錄信息發(fā)生變化，本地終端的通訊錄需要同步更新，由通訊錄同步模塊實現(xiàn)。
【基礎(chǔ)服務(wù)】
基礎(chǔ)服務(wù)包括統(tǒng)一認證和安全模塊，統(tǒng)一認證包括身份認證、單點登錄;安全模塊確保通訊錄服務(wù)的數(shù)據(jù)傳輸安全可靠。
單點登錄是指當(dāng)用戶請求通訊錄服務(wù)時，服務(wù)端需要對請求用戶的合法性進行驗證，合法用戶系統(tǒng)會提供通訊錄服務(wù)，否則返回?zé)o權(quán)訪問提示。用戶在服務(wù)請求中會涉及到如圖3 所示認證過程。
圖3 - 權(quán)限認證流程
① 客戶端向服務(wù)端發(fā)送通訊錄信息同步請求
② 通訊錄服務(wù)收到請求消息，會調(diào)用驗證模塊驗證用戶的合法性，即判斷用戶是否己登錄，已登錄執(zhí)行步驟 ⑤，未登錄執(zhí)行步驟 ③
③ 如用戶未登錄，客戶端返回身份認證頁面
④ 用戶在身份認證頁面填寫用戶名、密碼等相應(yīng)認證信息進行驗證
⑤ 如用戶已登錄，則根據(jù)用戶角色獲得訪問權(quán)限
⑥ 訪問 LDAP 數(shù)據(jù)庫，獲得通訊錄信息
⑦ 服務(wù)端返回相應(yīng)通訊錄信息
為增加企業(yè)通訊錄信息傳輸?shù)陌踩?，客戶端與服務(wù)端之間的數(shù)據(jù)傳輸本文采用SSL/TLS 加密，對存儲在數(shù)據(jù)庫中的數(shù)據(jù)進行加密存儲，以防泄露。
四、融合通信企業(yè)通訊錄業(yè)務(wù)相關(guān)接口
通訊錄服務(wù)需要對企業(yè)通信業(yè)務(wù)提供相對應(yīng)的接口支持，還要輔助其它業(yè)務(wù)獲得通信的相關(guān)信息。如圖4 所示，企業(yè)通訊錄服務(wù)提供了廣泛的接口支持企業(yè)通信業(yè)務(wù)和其它業(yè)務(wù)。
【I1 接口】
存在于客戶端與服務(wù)端之間，主要功能如下：
√ 使用 RESTful 實現(xiàn)客戶端對服務(wù)端的查詢和更新請求
√ 采用 TLS 安全協(xié)議保證信息數(shù)據(jù)的安全傳輸
圖4 - 通訊錄接口示意圖
【I2 接口】
位于Web 端和服務(wù)端之間，主要功能如下：
√ 通過 Web 實現(xiàn)對企業(yè)通訊錄的增加、刪除、修改、查詢等操作
√ 采用 TLS 安全協(xié)議保證信息數(shù)據(jù)的安全傳輸
【I3 接口】
位于服務(wù)端和IM 或語音視頻之類的通訊業(yè)務(wù)之間，使通訊業(yè)務(wù)能夠從通訊錄服務(wù)中查找到企業(yè)或個人的相關(guān)信息以便進行通信。
【I4 接口】
位于通訊錄服務(wù)和權(quán)限驗證模塊之間，客戶端或者其他實體業(yè)務(wù)對通訊錄服務(wù)的消息請求需要得到驗證，合法用戶才能使用通訊錄業(yè)務(wù)，該接口用于提供身份驗證服務(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)默認的屬性，管理員在進行員工信息操作時可根據(jù)需求進行屬性的添加或刪除。
目錄模式(Schema)的定義
本文中的企業(yè)通訊錄的數(shù)據(jù)是采用LDAP 協(xié)議描述的，它將數(shù)據(jù)庫中的數(shù)據(jù)抽象為樹形結(jié)構(gòu)，用戶只需對這棵樹的節(jié)點進行操作即可，降低了數(shù)據(jù) 操作的復(fù)雜性，真實的數(shù)據(jù)被存放到了一個關(guān)系型數(shù)據(jù)庫中，本文采用的是 MySQL。
除此之外，LDAP 提供了豐富的語言接口，有利于不同終端對LDAP 的操作。Schema (模式)是 LDAP 的 一 項重要內(nèi)容，它定義了數(shù)據(jù)的存儲格式。
比如定義一個節(jié)點有哪些屬性。本文采用的openLDAP 中包含一些標(biāo)準(zhǔn)的 Schema， 在 openLDAP 的 Schema 文件夾下，用戶也可以根據(jù)自己的需要來進行擴展，只需要在 Schema 文件夾下新建一個 Schema 文件來進行定義即可。
企業(yè)通訊錄是由企業(yè)所有員工組成的聯(lián)系人列表，并且與企業(yè)設(shè)置的組織架構(gòu)相對應(yīng)，實行層級管理。根據(jù)企業(yè)通訊錄功能的需要，部門和員工以及它們的信息形成了如圖5 所示的樹狀結(jié)構(gòu)。
圖5 - 企業(yè)通訊錄組織架構(gòu)圖
上文給出的是本文中擴展定義的Schema 文件，從上文看出 Schema 是由屬性、 對象類、幾配法則和語法四個重要元素組成。
首先給出了部門節(jié)點的屬性，由部門通信地址、部門名稱、部門編碼以及部門員工數(shù)量組成。然后給出了員工節(jié)點的屬性，有員工編號、員工姓名、性別、年齡、通信地址、手機號、SIP 號以及所屬部門組成，最后給出了部門節(jié)點和員工節(jié)點的對象類型，并將屬性添加到對象類型中。
基于RBAC 模型的細粒度權(quán)限訪問控制設(shè)計
細粒度是相對粗粒度而言的，細粒度權(quán)限訪問控制在RBAC(Role-Based Access Contro)模型中可理解為控制對最小權(quán)限單位客體的訪問，最小權(quán)限單位客體也就是不可再分割的客體，在企業(yè)通訊錄中最小權(quán)限單位是員工的個人信息如電話號碼。
企業(yè)通訊錄進行細粒度權(quán)限訪問控制，優(yōu)化了系統(tǒng)性能，減少系統(tǒng)代碼量和降低系統(tǒng)復(fù)雜度。
在使用粗粒度的權(quán)限管理系統(tǒng)中，為了授權(quán)對最小權(quán)限單位的訪問，不得不編寫大量邏輯代碼進行控制，增加了工程難度，不方便授權(quán)管理。
當(dāng)然，在實際的工程中很難達到最小化分解，只能盡可能進行細粒度分解(R5)。本文通過在原有的“角色-部門-員工”權(quán)限管理模型基礎(chǔ)上增加了“員工-信息”管理粒度使得權(quán)限得以細化，實現(xiàn)了最小權(quán)限訪問粒度的控制。
基于角色的訪問控制RBAC 模型中包含了一些基本概念，包括用戶、角色、權(quán)限、主客體、用戶-角色分配(URA)、角色-權(quán)限分配(PRA)以及會話。為了介紹 RBAC 模型，這里先介紹一下這些基本概念。
主體
主動進行訪問的對象，表現(xiàn)為系統(tǒng)用戶或代表用戶進行操作的進程。
客體
被訪問的對象，是一個被動實體，表現(xiàn)為操作系統(tǒng)中的文件或目錄，或者數(shù)據(jù)庫的表、行、字段等，也可以是一些外設(shè)圖投影儀、打印機等。
用戶
訪問系統(tǒng)數(shù)據(jù)或資源的主體，通常表現(xiàn)為人、系統(tǒng)進程或者代理等，大部分情況下指人
角色
通常指一個單位中的工作崗位，這個工作崗位具有特定權(quán)利與職責(zé)，擁有這個角色的人就具有了這種權(quán)利與職責(zé)。
權(quán)限
指被賦予了訪問模式的實體，訪問模式也可以說是訪問權(quán)利，即有權(quán)訪問哪些實體，權(quán)利包括讀、寫以及執(zhí)行，被訪問的實體與具體的應(yīng)用場景有關(guān)，可以是數(shù)據(jù)庫、通訊錄、以及外設(shè)等。
用戶-角色分配
將角色分配給用戶，一個用戶可以擁有多種角色，分配過后用戶擁有角色相應(yīng)的職責(zé)和權(quán)利。
角色-權(quán)限分配
將權(quán)限分配給角色，一個角色可以被分配多種權(quán)限，分配過后角色擁有訪問系統(tǒng)資源的能力。
會話
指用戶激活角色的過程，參與者有一個用戶以及一組激活的角色。建立新會話可以激活新的角色。
在用戶與權(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é)的不同將對應(yīng)權(quán)限分配給它們，建立角色-權(quán)限的關(guān)系后，不同的角色就會有不同的訪問權(quán)限。根據(jù)用戶擔(dān)任的崗位，將對應(yīng)的角色分配給它們，建立用戶-角色的關(guān)系，這就是 RBAC (基于角色的訪問控制)的主要思想。
圖6 - RBAC授權(quán)示意圖
RBAC 模型解耦了用戶與權(quán)限之間的直接聯(lián)系，通過角色與權(quán)限關(guān)聯(lián)以及用戶與角色關(guān)聯(lián)這兩部分，實現(xiàn)了通過角色給用戶分配權(quán)限;一個用戶可以有多種角色，一個角色可以有多種權(quán)限。RBAC 的這種設(shè)計，極大地方便了授權(quán)的管理。
RBAC 模型主要涉及到以下元素：
實體集
用戶集U(Users)、角色集 R(Roles)、權(quán)限集 P(Permissions)、會話集 S(Sessions)
實體關(guān)系
PA(PxR)為角色分配權(quán)限：UA(UxR)為用戶分配角色;RH(RxR)為角色層次。系統(tǒng)管理員可根據(jù)實際系統(tǒng)的需求創(chuàng)建角色，給角色分配權(quán)限并給不同用戶分配相應(yīng)的角色。角色和權(quán)限之間，以及用戶和角色之間都是多對多的關(guān)系，其模型圖 7 所示。
RBAC 最大的特點是用戶通過角色來獲得訪問權(quán)限，這樣做增加了權(quán)限管理的靈活性，可以減少管理上的錯誤。
當(dāng)用戶在公司的職位發(fā)生變化時，只需要移去員工原來的角色并重新分配新職位對應(yīng)的角色即可，避免因人員職位調(diào)動導(dǎo)致的重新授權(quán)。當(dāng)公司的組織架構(gòu)發(fā)生變化時，角色也可以根據(jù)公司新的組織架構(gòu)重新設(shè)置。
除此之外，角色也可以像部門的層級關(guān)系那樣具有繼承關(guān)系，高級角色可以繼承低級角色的訪問權(quán)限。這些都是RBAC 授權(quán)靈活性的表現(xiàn)，當(dāng)然也降低了企業(yè)進行授權(quán)管理的成本。
圖7 - RBAC關(guān)聯(lián)關(guān)系
基于“角色-部門-員工-信息”細粒度訪問權(quán)限控制的信息模型設(shè)計
節(jié)點的群組化
圖8 - 節(jié)點群組化示意圖
由于企業(yè)部門和員工數(shù)量很多，管理員在創(chuàng)建權(quán)限時不可能去設(shè)置一種角色對每一個部門以及每一個員工的訪問權(quán)限，為了方便權(quán)限設(shè)置，本文將功能和職責(zé)相似的部門以及員工看作是同一類型，在創(chuàng)建部門和員工時系統(tǒng)會為它們分配固有type 屬性，具有相同的 type 類型可看成是同一群組，管理員在設(shè)置可見性時不需要去設(shè)置對每一個部門或員工的可見性，只需要設(shè)置對部門群組和員工群組的可見性即可，示例如圖 8 所示。
三級權(quán)限
基于“角色-部門-員工-信息”細粒度訪問控制概念，本文所提“角色-部門-員工-信息”的權(quán)限分級模型，由三級權(quán)限組成。企業(yè)通訊錄由多個部門組成，每個部門下又包含多個員工，每個員工都有各種個人信息，這些具體的個人信息可認為是不可分解最小單位。
在我們的“角色-部門-員工-信息”模型中，員工的這些個人信息屬于最小級別權(quán)限——三級權(quán)限，包含這些信息的個人是它們的父級權(quán)限——二級權(quán)限，包含員工的部門擁有最大權(quán)限級別——一級權(quán)限。
權(quán)限的分配
基于“角色-部門-員工-信息”細粒度訪問控制概念原理，由于不同角色的用戶對系統(tǒng)的訪問權(quán)限不同。因此，用戶在進入系統(tǒng)后，系統(tǒng)根據(jù)用戶的 ID 查詢到用戶的權(quán)限集合，根據(jù)一級權(quán)限給客戶端返回可見部門，根據(jù)二級權(quán)限返回可見員工，客戶端收到返回信息后可生成本地通訊錄的部門菜單以及各部門下所包含的員工，然后根據(jù)三級權(quán)限系統(tǒng)給客戶端返回相應(yīng)的個人信息。最后客戶端將接收到的消息進行解析即可獲得本地通訊錄。
根據(jù)以上分析，管理員在進行訪問權(quán)限管理時，首先需要設(shè)置各級權(quán)限，其次，將權(quán)限分配給角色，最后將角色分配給員工，即可完成員工對通訊錄訪問權(quán)限的控制。
圖9 - 權(quán)限管理模型圖
通過以上分析，基于“角色-部門-員工-信息”的權(quán)限分級模型實現(xiàn)了權(quán)限的 細粒度訪問控制，把對權(quán)限的控制最小化到了員工的具體個人信息;并根據(jù) RBAC 的訪問控制模型，得出了基手“角色-部門-員工-信息”的權(quán)限管理模型圖如圖 9 所示。
實體關(guān)系模型
實體關(guān)系模型基于“角色-部門-員工-信息”的分級細粒度權(quán)限控制模型，有效的實現(xiàn)了用戶的訪問權(quán)限控制，其實體關(guān)系圖如圖 10 所示。
圖10 - 實體關(guān)系模型
從上文的E-R 模型圖可得到幾張表：
①部門表：定義部門及其屬性
②用戶表：定義用戶及其屬性
③角色表：定義角色及其屬性
④一級權(quán)限表：定義對部門的訪問權(quán)限
⑤二級權(quán)限表：定義對部門下員工的訪問權(quán)限
⑥三級權(quán)限表：定義對員工信息的訪問權(quán)限
⑦ 部門用戶表：定義員工對各個部門的從屬關(guān)系
⑧用戶角色表：定義用戶對各個角色的從屬關(guān)系
⑨角色權(quán)限表：定義用戶對部門、員工、個人信息的訪問關(guān)系
數(shù)據(jù)庫的設(shè)計
系統(tǒng)的部門信息、用戶信息以及它們之間的從屬關(guān)系，會采用LDAP 數(shù)據(jù)庫表示，在此給出的部門、員工表設(shè)計僅僅是為了闡明涉及到的實體之間的邏輯關(guān)系。
剩下的各個表采用MySQL 存儲，數(shù)據(jù)庫設(shè)計如圖 11 所示。
圖11 - 權(quán)限數(shù)據(jù)庫設(shè)計
根據(jù)RBAC 思想，用戶、角色、權(quán)限相互獨立，分別通過用戶角色表和角色權(quán)限表進行關(guān)聯(lián)，用戶角色表中通過引用用戶表中的主鍵用戶 ID 作為外鍵和用戶表關(guān)聯(lián)，通過引用角色表中的主鍵角色 ID 作為外鍵和角色表關(guān)聯(lián);角色權(quán)限表中通過引用角色表中的主鍵角色 ID 作為外鍵和角色關(guān)聯(lián)，通過引用各級權(quán)限表中的主鍵權(quán)限 ID 作為外鍵和各級權(quán)限表關(guān)聯(lián);部門和用戶表中各有一個類型字段，該字段用于部門和員工的群組化管理，方便管理員的權(quán)限控制。
關(guān)注【融云 RongCloud】，了解更多干貨。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
