關於權限方案設計「轉」

最近接手公司信息化建設,對權限的設計也是仁者見仁,智者見智了,我這裡寫了一篇說明書,希望對大家有所幫助。



企業信息化權限方案設計說明書

  1 摘要

  權限設計是每一個系統的重要組成部分,主要用於控制功能和流程,以滿足不同系統用戶的需求,提高系統安全性,成為應用系統不可缺少的一部分,而設計一個相對通用的權限系統更具有很大意義。

  本文將列舉目前幾種常見的權限設計方案,對比其優勢、劣勢,結合企業信息化需求,設計合適地權限方案。

  2 需求說明

  2.1 不同職責的人,對於系統操作的權限應該是不同的。

  2.2 可以以“組”的形式對權限進行分配。

對於一個業務比較繁多的企業信息化平臺來說,如果要求管理員為員工逐一分配系統操作權限的話,是件耗時且不夠方便的事情。所以,系統中應以“組”的形式對權限進行分配,將權限一致的人員編入同一組,然後對該組進行權限分配。

  2.3 權限管理系統應該是可擴展的。

要求權限的設計可以加入到任何帶有權限管理功能的系統中。就像組件一樣可以被不斷的重用,而不是每開發一套管理系統,就要針對權限管理部分進行重新開發。

  2.4 滿足業務系統中的功能權限。

在業務系統中,存在著兩種權限管理,一種是功能權限的管理,另一種則是資源權限的管理,在不同系統組件之間,功能權限是可重用的,而資源權限則不能。

  3 定義

  CRUD:分別指Create創建、Read讀取、Update更新、Delete刪除。

  RBAC(Role-Based Access Control):基於角色的訪問控制。

  4 環境

  開發工具:Microsoft Visual Studio 2010 EN

  開發語言:C#

  開發模型:ADO.Net Entity Framework

  5 常見權限

  5.1 等級權限方案

在這種系統中,權限級別如同官階從低到高排列,每個用戶擁有一個權限,其中設定了這個用戶的權限等級,在用戶需要執行操作前先查看其權限等級是否大於執行操作所需要的權限等級,是則進行操作。

這種權限方案在論壇中很常見,用戶類基本屬性如下:

Id // 用戶ID

Name // 用戶名

權限類基本屬性如下:

Id // 權限ID

UserId // 權限對應用戶ID

Level // 用戶權限等級

權限可執行功能如下:

0 訪問

1 可跟帖

2 可創建主帖

3 可刪除主帖

4 可創建頻道

5 可刪除頻道

6 可查看用戶

7 可分配用戶權限

8 可修改用戶密碼

9 可刪除用戶

……

使用的時候,獲取用戶對應操作的權限等級與權限等表進行比較,高於目標權限等級即可進行當前操作,否則拋出權限不夠。

以上等級權限適用於小型項目開發,而且需求較為單一者,同樣權限等級也較少,如果每一個用戶對應多個模塊,每一個模塊都具有相同的權限分配,就需要對以上權限方案進行更改,在權限類中增加模塊編號,才能進行正常判斷,可見此權限分配方案使用起來簡單,但卻有最致命的一點,那就是擴展性太差,靈活性不高,不適用於大型項目開發以及邏輯比較複雜的業務。

  5.2 單純用戶等級權限方案

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

這種權限分配用戶類基本屬性如下:

Id // 用戶ID

Name // 用戶名

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

Id // 用戶等級ID

Name // 用戶等級名稱

UserId // 用戶ID

權限類基本屬性如下:

Id // 權限編號

UserLevelId // 用戶等級ID

用戶可執行操作均在權限類中定義,在程序中對每一個權限操作進行判斷,如果所屬用戶等級中包含此權限,可進行當前操作,否則拋出沒有當前操作權限。

這種權限方案可以解決中小型業務需求,對於業務繁雜的企業信息平臺,其不致命之處依然是可擴展性太差,靈活性不高,對於不同模塊仍需要重新定義權限類,一方面造成用戶等級的分配臃腫,每一個權限對應CRUD也無法細分。

  5.3 基於RBAC動態權限分配

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

  RBAC具有如下特點:

    2、 授權管理機制更加接近實際、更加社會化;

    3、 用戶、角色和權限是多對多的關係;

    4、 系統的操作用戶與數據對象沒有直接的聯繫。

  本文正是採用此種權限分配方案,並結合企業信息化需求設計,參考Membership機制去除對於分組的控制。

  具體設計模型如下:

Member:信息化平臺成員類

Module:信息化平臺組件類

Limit:信息化平臺所有權限

Action:信息化平臺權限所對應的操作(CRUD)

Role:信息化平臺角色類

關於權限方案設計「轉」



原文地址:https://www.cnblogs.com/hsinlu/archive/2010/10/17/1853648.html


分享到:


相關文章: