|
|
最近接手公司信息化建設(shè)，對(duì)權(quán)限的設(shè)計(jì)也是仁者見(jiàn)仁，智者見(jiàn)智了，我這里寫了一篇說(shuō)明書，希望對(duì)大家有所幫助。
企業(yè)信息化權(quán)限方案設(shè)計(jì)說(shuō)明書
1 摘要
權(quán)限設(shè)計(jì)是每一個(gè)系統(tǒng)的重要組成部分，主要用于控制功能和流程，以滿足不同系統(tǒng)用戶的需求，提高系統(tǒng)安全性，成為應(yīng)用系統(tǒng)不可缺少的一部分，而設(shè)計(jì)一個(gè)相對(duì)通用的權(quán)限系統(tǒng)更具有很大意義。
本文將列舉目前幾種常見(jiàn)的權(quán)限設(shè)計(jì)方案，對(duì)比其優(yōu)勢(shì)、劣勢(shì)，結(jié)合企業(yè)信息化需求，設(shè)計(jì)合適地權(quán)限方案。
2 需求說(shuō)明
2.1 不同職責(zé)的人，對(duì)于系統(tǒng)操作的權(quán)限應(yīng)該是不同的。
2.2 可以以“組”的形式對(duì)權(quán)限進(jìn)行分配。
對(duì)于一個(gè)業(yè)務(wù)比較繁多的企業(yè)信息化平臺(tái)來(lái)說(shuō)，如果要求管理員為員工逐一分配系統(tǒng)操作權(quán)限的話，是件耗時(shí)且不夠方便的事情。所以，系統(tǒng)中應(yīng)以“組”的形式對(duì)權(quán)限進(jìn)行分配，將權(quán)限一致的人員編入同一組，然后對(duì)該組進(jìn)行權(quán)限分配。
2.3 權(quán)限管理系統(tǒng)應(yīng)該是可擴(kuò)展的。
要求權(quán)限的設(shè)計(jì)可以加入到任何帶有權(quán)限管理功能的系統(tǒng)中。就像組件一樣可以被不斷的重用，而不是每開發(fā)一套管理系統(tǒng)，就要針對(duì)權(quán)限管理部分進(jìn)行重新開發(fā)。
2.4 滿足業(yè)務(wù)系統(tǒng)中的功能權(quán)限。
在業(yè)務(wù)系統(tǒng)中，存在著兩種權(quán)限管理，一種是功能權(quán)限的管理，另一種則是資源權(quán)限的管理，在不同系統(tǒng)組件之間，功能權(quán)限是可重用的，而資源權(quán)限則不能。
3 定義
CRUD：分別指Create創(chuàng)建、Read讀取、Update更新、Delete刪除。
RBAC(Role-Based Access Control)：基于角色的訪問(wèn)控制。
4 環(huán)境
開發(fā)工具：Microsoft Visual Studio 2010 EN
開發(fā)語(yǔ)言：C#
開發(fā)模型：ADO.NET Entity Framework
5 常見(jiàn)權(quán)限
5.1 等級(jí)權(quán)限方案
在這種系統(tǒng)中，權(quán)限級(jí)別如同官階從低到高排列，每個(gè)用戶擁有一個(gè)權(quán)限，其中設(shè)定了這個(gè)用戶的權(quán)限等級(jí)，在用戶需要執(zhí)行操作前先查看其權(quán)限等級(jí)是否大于執(zhí)行操作所需要的權(quán)限等級(jí)，是則進(jìn)行操作。
這種權(quán)限方案在論壇中很常見(jiàn)，用戶類基本屬性如下：
Id // 用戶ID
Name // 用戶名
權(quán)限類基本屬性如下：
Id // 權(quán)限ID
UserId // 權(quán)限對(duì)應(yīng)用戶ID
Level // 用戶權(quán)限等級(jí)
權(quán)限可執(zhí)行功能如下：
0 訪問(wèn)
1 可跟帖
2 可創(chuàng)建主帖
3 可刪除主帖
4 可創(chuàng)建頻道
5 可刪除頻道
6 可查看用戶
7 可分配用戶權(quán)限
8 可修改用戶密碼
9 可刪除用戶
……
使用的時(shí)候，獲取用戶對(duì)應(yīng)操作的權(quán)限等級(jí)與權(quán)限等表進(jìn)行比較，高于目標(biāo)權(quán)限等級(jí)即可進(jìn)行當(dāng)前操作，否則拋出權(quán)限不夠。
以上等級(jí)權(quán)限適用于小型項(xiàng)目開發(fā)，而且需求較為單一者，同樣權(quán)限等級(jí)也較少，如果每一個(gè)用戶對(duì)應(yīng)多個(gè)模塊，每一個(gè)模塊都具有相同的權(quán)限分配，就需要對(duì)以上權(quán)限方案進(jìn)行更改，在權(quán)限類中增加模塊編號(hào)，才能進(jìn)行正常判斷，可見(jiàn)此權(quán)限分配方案使用起來(lái)簡(jiǎn)單，但卻有最致命的一點(diǎn)，那就是擴(kuò)展性太差，靈活性不高，不適用于大型項(xiàng)目開發(fā)以及邏輯比較復(fù)雜的業(yè)務(wù)。
5.2 單純用戶等級(jí)權(quán)限方案
這種權(quán)限分配在大多數(shù)小型辦公軟件中常用，目前也在很多場(chǎng)合使用，系統(tǒng)定義多個(gè)用戶等級(jí)，如“超級(jí)管理員”、“普通管理員”、“匿名用戶”，為每一個(gè)用戶等級(jí)分配不同的權(quán)限，每一個(gè)用戶對(duì)應(yīng)一個(gè)用戶等級(jí)，程序啟動(dòng)時(shí)根據(jù)登錄用戶的等級(jí)對(duì)窗體進(jìn)行配置，對(duì)沒(méi)有權(quán)限的菜單設(shè)置為隱藏或不可用。
這種權(quán)限分配用戶類基本屬性如下：
Id // 用戶ID
Name // 用戶名
用戶等級(jí)類基本屬性如下：
Id // 用戶等級(jí)ID
Name // 用戶等級(jí)名稱
UserId // 用戶ID
權(quán)限類基本屬性如下：
Id // 權(quán)限編號(hào)
UserLevelId // 用戶等級(jí)ID
用戶可執(zhí)行操作均在權(quán)限類中定義，在程序中對(duì)每一個(gè)權(quán)限操作進(jìn)行判斷，如果所屬用戶等級(jí)中包含此權(quán)限，可進(jìn)行當(dāng)前操作，否則拋出沒(méi)有當(dāng)前操作權(quán)限。
這種權(quán)限方案可以解決中小型業(yè)務(wù)需求，對(duì)于業(yè)務(wù)繁雜的企業(yè)信息平臺(tái)，其不致命之處依然是可擴(kuò)展性太差，靈活性不高，對(duì)于不同模塊仍需要重新定義權(quán)限類，一方面造成用戶等級(jí)的分配臃腫，每一個(gè)權(quán)限對(duì)應(yīng)CRUD也無(wú)法細(xì)分。
5.3 基于RBAC動(dòng)態(tài)權(quán)限分配
RBAC的核心思想是把訪問(wèn)權(quán)限賦給角色而不是用戶，用戶通過(guò)它所屬的角色來(lái)獲得訪問(wèn)權(quán)限，具有更強(qiáng)的靈活性和更廣泛的適用性。它主要引入了角色這一概念，角色的實(shí)質(zhì)是一個(gè)或一群用戶在組織內(nèi)可執(zhí)行的操作的集合。在RBAC內(nèi),角色為訪問(wèn)控制的主體，角色決定了用戶對(duì)資源所擁有的權(quán)限以及可以執(zhí)行的操作，其中訪問(wèn)控制策略在RBAC中主要體現(xiàn)為用戶/角色、角色/權(quán)限和角色/角色之間的關(guān)系。
RBAC具有如下特點(diǎn):
1、 授權(quán)管理靈活；
2、 授權(quán)管理機(jī)制更加接近實(shí)際?更加社會(huì)化；
3、 用戶?角色和權(quán)限是多對(duì)多的關(guān)系；
4、 系統(tǒng)的操作用戶與數(shù)據(jù)對(duì)象沒(méi)有直接的聯(lián)系?
本文正是采用此種權(quán)限分配方案，并結(jié)合企業(yè)信息化需求設(shè)計(jì)，參考Membership機(jī)制去除對(duì)于分組的控制。
具體設(shè)計(jì)模型如下：
Member：信息化平臺(tái)成員類
Module：信息化平臺(tái)組件類
Limit：信息化平臺(tái)所有權(quán)限
Action：信息化平臺(tái)權(quán)限所對(duì)應(yīng)的操作（CRUD）
Role：信息化平臺(tái)角色類
it知識(shí)庫(kù)：關(guān)于權(quán)限方案設(shè)計(jì)，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
