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