最近接手公司信息化建設(shè)，對權(quán)限的設(shè)計也是仁者見仁，智者見智了，我這里寫了一篇說明書，希望對大家有所幫助。

企業(yè)信息化權(quán)限方案設(shè)計說明書

　　1 摘要

　　權(quán)限設(shè)計是每一個系統(tǒng)的重要組成部分，主要用于控制功能和流程，以滿足不同系統(tǒng)用戶的需求，提高系統(tǒng)安全性，成為應(yīng)用系統(tǒng)不可缺少的一部分，而設(shè)計一個相對通用的權(quán)限系統(tǒng)更具有很大意義。

　　本文將列舉目前幾種常見的權(quán)限設(shè)計方案，對比其優(yōu)勢、劣勢，結(jié)合企業(yè)信息化需求，設(shè)計合適地權(quán)限方案。

　　2 需求說明

　　2.1 不同職責(zé)的人，對于系統(tǒng)操作的權(quán)限應(yīng)該是不同的。

　　2.2 可以以“組”的形式對權(quán)限進(jìn)行分配。

     對于一個業(yè)務(wù)比較繁多的企業(yè)信息化平臺來說，如果要求管理員為員工逐一分配系統(tǒng)操作權(quán)限的話，是件耗時且不夠方便的事情。所以，系統(tǒng)中應(yīng)以“組”的形式對權(quán)限進(jìn)行分配，將權(quán)限一致的人員編入同一組，然后對該組進(jìn)行權(quán)限分配。

　　2.3 權(quán)限管理系統(tǒng)應(yīng)該是可擴(kuò)展的。

     要求權(quán)限的設(shè)計可以加入到任何帶有權(quán)限管理功能的系統(tǒng)中。就像組件一樣可以被不斷的重用，而不是每開發(fā)一套管理系統(tǒng)，就要針對權(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)：基于角色的訪問控制。

　　4 環(huán)境

　　開發(fā)工具：Microsoft Visual Studio 2010 EN

　　開發(fā)語言：C#

　　開發(fā)模型：ADO.NET Entity Framework

　　5 常見權(quán)限

　　5.1 等級權(quán)限方案

     在這種系統(tǒng)中，權(quán)限級別如同官階從低到高排列，每個用戶擁有一個權(quán)限，其中設(shè)定了這個用戶的權(quán)限等級，在用戶需要執(zhí)行操作前先查看其權(quán)限等級是否大于執(zhí)行操作所需要的權(quán)限等級，是則進(jìn)行操作。

     這種權(quán)限方案在論壇中很常見，用戶類基本屬性如下：

     Id   // 用戶ID

     Name // 用戶名

     權(quán)限類基本屬性如下：

     Id   // 權(quán)限ID

     UserId // 權(quán)限對應(yīng)用戶ID

     Level // 用戶權(quán)限等級

     權(quán)限可執(zhí)行功能如下：

     0 訪問

     1 可跟帖

     2 可創(chuàng)建主帖

     3 可刪除主帖

     4 可創(chuàng)建頻道

     5 可刪除頻道

     6 可查看用戶

     7 可分配用戶權(quán)限

     8 可修改用戶密碼

     9 可刪除用戶

     ……

     使用的時候，獲取用戶對應(yīng)操作的權(quán)限等級與權(quán)限等表進(jìn)行比較，高于目標(biāo)權(quán)限等級即可進(jìn)行當(dāng)前操作，否則拋出權(quán)限不夠。

     以上等級權(quán)限適用于小型項目開發(fā)，而且需求較為單一者，同樣權(quán)限等級也較少，如果每一個用戶對應(yīng)多個模塊，每一個模塊都具有相同的權(quán)限分配，就需要對以上權(quán)限方案進(jìn)行更改，在權(quán)限類中增加模塊編號，才能進(jìn)行正常判斷，可見此權(quán)限分配方案使用起來簡單，但卻有最致命的一點(diǎn)，那就是擴(kuò)展性太差，靈活性不高，不適用于大型項目開發(fā)以及邏輯比較復(fù)雜的業(yè)務(wù)。

　　5.2 單純用戶等級權(quán)限方案

     這種權(quán)限分配在大多數(shù)小型辦公軟件中常用，目前也在很多場合使用，系統(tǒng)定義多個用戶等級，如“超級管理員”、“普通管理員”、“匿名用戶”，為每一個用戶等級分配不同的權(quán)限，每一個用戶對應(yīng)一個用戶等級，程序啟動時根據(jù)登錄用戶的等級對窗體進(jìn)行配置，對沒有權(quán)限的菜單設(shè)置為隱藏或不可用。

     這種權(quán)限分配用戶類基本屬性如下：

     Id  // 用戶ID

     Name // 用戶名

     用戶等級類基本屬性如下：

     Id  // 用戶等級ID

     Name  // 用戶等級名稱

     UserId // 用戶ID

     權(quán)限類基本屬性如下：

     Id  // 權(quán)限編號

     UserLevelId  // 用戶等級ID

     用戶可執(zhí)行操作均在權(quán)限類中定義，在程序中對每一個權(quán)限操作進(jìn)行判斷，如果所屬用戶等級中包含此權(quán)限，可進(jìn)行當(dāng)前操作，否則拋出沒有當(dāng)前操作權(quán)限。

     這種權(quán)限方案可以解決中小型業(yè)務(wù)需求，對于業(yè)務(wù)繁雜的企業(yè)信息平臺，其不致命之處依然是可擴(kuò)展性太差，靈活性不高，對于不同模塊仍需要重新定義權(quán)限類，一方面造成用戶等級的分配臃腫，每一個權(quán)限對應(yīng)CRUD也無法細(xì)分。

　　5.3 基于RBAC動態(tài)權(quán)限分配

     RBAC的核心思想是把訪問權(quán)限賦給角色而不是用戶，用戶通過它所屬的角色來獲得訪問權(quán)限，具有更強(qiáng)的靈活性和更廣泛的適用性。它主要引入了角色這一概念，角色的實(shí)質(zhì)是一個或一群用戶在組織內(nèi)可執(zhí)行的操作的集合。在RBAC內(nèi),角色為訪問控制的主體，角色決定了用戶對資源所擁有的權(quán)限以及可以執(zhí)行的操作，其中訪問控制策略在RBAC中主要體現(xiàn)為用戶/角色、角色/權(quán)限和角色/角色之間的關(guān)系。

　　RBAC具有如下特點(diǎn):

　　　　1、 授權(quán)管理靈活；

　　　　2、 授權(quán)管理機(jī)制更加接近實(shí)際?更加社會化；

　　　　3、 用戶?角色和權(quán)限是多對多的關(guān)系；

　　　　4、 系統(tǒng)的操作用戶與數(shù)據(jù)對象沒有直接的聯(lián)系?

　　本文正是采用此種權(quán)限分配方案，并結(jié)合企業(yè)信息化需求設(shè)計，參考Membership機(jī)制去除對于分組的控制。

　　具體設(shè)計模型如下：

     Member：信息化平臺成員類

     Module：信息化平臺組件類

     Limit：信息化平臺所有權(quán)限

     Action：信息化平臺權(quán)限所對應(yīng)的操作（CRUD）

     Role：信息化平臺角色類

it知識庫：關(guān)于權(quán)限方案設(shè)計，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。