企業(yè)通訊錄作為企業(yè)統(tǒng)一通信中其它業(yè)務(wù)功能的觸發(fā)點(diǎn)，需要靈活、完備的功能和好用、便捷的人機(jī)界面，以便用戶(hù)順利完成業(yè)務(wù)協(xié)作，真正為企業(yè)運(yùn)轉(zhuǎn)提速，實(shí)現(xiàn)降本增效。

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

一、需求分析

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

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

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

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

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

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

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

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

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

通訊錄信息實(shí)時(shí)同步保證了用戶(hù)本地通訊錄與服務(wù)端通訊錄的一致性;細(xì)粒度訪問(wèn)權(quán)限控制保證了用戶(hù)能夠獲得正確的通訊錄信息;統(tǒng)一認(rèn)證服務(wù)保證了企業(yè)合法用戶(hù)無(wú)需重復(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ù)庫(kù)接入層，各模塊之間的通信采用消息總線的方式，即模塊之間不會(huì)直接發(fā)送消息而是將消息發(fā)送到消息隊(duì)列中，采用這種通信方式可以降低模塊之間的耦合度，便于系統(tǒng)模塊的擴(kuò)展和維護(hù)。

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

　　三、功能與模塊

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

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

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

一類(lèi)是為Web 端提供服務(wù)稱(chēng)為 Web 端服務(wù)。

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

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

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

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

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

√ 角色管理和權(quán)限管理模塊是用來(lái)實(shí)現(xiàn)員工訪問(wè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)用戶(hù)請(qǐng)求通訊錄服務(wù)時(shí)，服務(wù)端需要對(duì)請(qǐng)求用戶(hù)的合法性進(jìn)行驗(yàn)證，合法用戶(hù)系統(tǒng)會(huì)提供通訊錄服務(wù)，否則返回?zé)o權(quán)訪問(wèn)提示。用戶(hù)在服務(wù)請(qǐng)求中會(huì)涉及到如圖3 所示認(rèn)證過(guò)程。

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

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

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

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

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

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

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

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

為增加企業(yè)通訊錄信息傳輸?shù)陌踩裕蛻?hù)端與服務(wù)端之間的數(shù)據(jù)傳輸本文采用SSL/TLS 加密，對(duì)存儲(chǔ)在數(shù)據(jù)庫(kù)中的數(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 接口】

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

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

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

圖4 - 通訊錄接口示意圖

【I2 接口】

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

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

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

【I3 接口】

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

【I4 接口】

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

【I5 接口】

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

【I6 接口】

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

通訊錄信息模型

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

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

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

目錄模式(Schema)的定義

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

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

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

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

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

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

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

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

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

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

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

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

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

主體

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

客體

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

用戶(hù)

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

角色

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

權(quán)限

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

用戶(hù)-角色分配

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

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

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

會(huì)話

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

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

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

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

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

實(shí)體集

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

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

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

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

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

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

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

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

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

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

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

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

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

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

權(quán)限的分配

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

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

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

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

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

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

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

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

①部門(mén)表：定義部門(mén)及其屬性

②用戶(hù)表：定義用戶(hù)及其屬性

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

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

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

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

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

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

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

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

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

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

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

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

關(guān)注【融云 RongCloud】，了解更多干貨。

（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。 ）