基於組織角色的許可權設計

好久沒有寫部落格了，最近研究了一下許可權方面的資料，和大家分享一下基於組織角色的許可權設計思路。

一、目標：

可以對功能進行許可權控制，控制粒度可以達到頁面級別和控制項級別

可以對資料進行許可權控制

可以按角色、按人、按部門、按崗位等授權，

可以分級授權，方便管理

二、設計思路

1. 模組

模組是乙個抽象的概念，大到可以表示乙個系統，小到可以表示乙個控制項的功能，包括了選單、模組、頁面、功能、資料許可權及資料許可權表示式等。

1) 選單：是乙個指向某個功能的指標，指向乙個頁面或者功能，所以可以將其視為乙個功能。

2) 模組：頁面功能的分類，模組下面擁在子模組和頁面。

3) 頁面：呈現給終端使用者的介面，使用者通過頁面來和系統互動，根據系統的不同，bs架構時是web頁面， cs架構時是windows介面。

4) 控制項功能：每個介面上的控制項，例如儲存、刪除等按鈕所代表的功能，某個控制項的顯示功能等

5) 資料許可權：標識乙個需要進行許可權控制的資料集合，下面包含多個許可權表示式，每乙個表示式就是乙個sql語句的where條件的一部分。例如檢視全部的表示式是 1= 1，檢視本部門的資料的表示式是 departmentid = 『$user.departid$』、檢視我的資料的表示式是userid = 『$user.userid$』。

6) 許可權表示式：用來對資料進行過濾，本質上是乙個sql語句的where條件的一部分。每個表示式都擁有優先順序，當同時擁有多個表示式時，取優先順序高的表示式。

2. 角色

角色是一組功能的集合，乙個角色包含了多個功能許可權，方便管理員進行授權，例如系統管理員擁有後台管理的功能，後台管理的功能包括相關選單的許可權、相關介面及控制項的操作許可權。

3. 組織

組織分為公司、部門、崗位和人員4級，其中公司和部門可以自迴圈，公司下面可以有子公司，部門下面可以有子部門。

授權時，將角色分配給組織上的節點，可以將角色分配給公司、部門、崗位和人員，下級節點自動繼承上級組織的許可權，給某個部門分配角色後，該部門下面的子部門和相關人員就都具有了該角色所擁有的許可權。當某個人歸屬到組織上後，就自動擁有組織的許可權。在分配許可權時，採用許可權遞增的原則進行分配。

4. 分級授權

分級授權時，只能分配那些分配給組織的許可權，這個和組織所擁有的許可權是不同的，例如某個組織節點擁有10項許可權，但是可以分配的許可權可能只是這10個中的一部分。

5. 相關問題

1) 使用者和組織中的人員是什麼關係？

人員是使用者與組織的關係的表示，如果乙個人只有乙個崗位，那麼在組織中就會有乙個人員。如果使用者在組織中有多個崗位，即一人多崗的情況，那麼在組織中就會有多個人員。

2) 授權時，為什麼不直接把模組分配給組織，而要先把模組分配給角色，再把角色分配給組織？

因為模組中的功能粒度過細，使用者的管理員分不清楚每乙個模組具體有什麼功能，但使用者知道角色代表的意義。例如使用者的管理員知道會計角色，但是不知道會計具體使用哪些功能。

這樣角色和組織中的崗位會有一定的重疊，但是兩者又有一些區別。組織中的崗位是使用者在實際生活中的角色，而系統中的角色是為了方便許可權管理而設定的，即許可權角色。實際生活中的角色可能擁有多個許可權角色。例如總經理可能擁有全部的許可權角色，而在組織中總經理是乙個崗位。

三、庫表設計

相關表以cm_開頭（ common的簡寫）

序號表名說明1

cm_user使用者2

cm_org組織3

cm_orgrole

組織角色

4cm_role角色5

cm_rolemodule

角色功能

6cm_module功能7

cm_orgmanmodule

組織管理的功能（分級授權用）

庫表關係圖:

四、後續思考

1、系統應該基於角色的許可權控制。

2、角色有層級關係，其作用主要用於角色管理，而不是許可權繼承。

3、組織代表了角色，當組織存在的時候，可以讓程式自動為每個組織中的節點建立乙個角色，以避免組織與角色的重疊。

4、人員與組織是多對多關係，應該要建立乙個組織人員表，而不是將人員也歸到組織表中去。

5、為了方便授權，應該有以下幾個功能：按功能授權，按角色授權（包括按人授權）

6、有組織的按組織授權，沒有組織的按角色授權

基於組織角色的許可權設計

基於角色的許可權設計

基於角色的許可權設計

基於角色的許可權設計

基於組織角色的許可權設計

基於角色的許可權設計

基於角色的許可權設計

基於角色的許可權設計

相關推薦