基於角色的權限設計

基於角色的權限設計（一）

在任何系統中，權限設計是最基礎的東西，本文給出一個基於角色的權限設計的循序漸進的設計方案。

　　在權限系統中，功能（權限）是最小的單位，比如起草新聞、編輯新聞、審覈新聞、刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞、編輯新聞等功能集合，而責任編輯他可能就有更多的權限，比如除了新聞編輯的功能，還有審覈新聞、刪除新聞等功能，給張三賦予新聞編輯的角色（其實我更願意說把張三加入到新聞編輯這個角色中去），張三就可以起草新聞、編輯新聞了，給李四賦予責任編輯的角色，李四就可以起草新聞、編輯新聞、審覈新聞、刪除新聞了。

　　我們來看看版本一的解決方案：


 

　　我們來模擬一下上面的數據：

　　用戶信息表：

UserID	UserName
U1	張三
U2	李四

　　角色表：

RoleID	RoleName
R1	新聞編輯
R2	責任編輯

　　角色用戶表：

RoleID	UserID
R1	U1
R2	U2

　　功能表：

FunctionID	FunctionName
F1	起草新聞
F2	編輯新聞
F3	審覈新聞
F4	刪除新聞

　　角色功能表：

RoleID	FunctionID
R1	F1
R1	F2
R2	F1
R2	F2
R2	F3
R2	F4

　　我們來看看如何判斷一個用戶具有某個功能權限：

　　首先在用戶張三登錄的時候，獲取張三的全部功能列表：

Select FunctionID From 角色功能表 Where RoleID In (Select RoleID From 用戶角色表 Where UserID=’U1’)

　　這樣就可以得到張三的全部功能列表Functions，在起草新聞的頁面我們就可以做如下判斷：

Functions.Contain(‘F1’);//當然你可以把這個’F1’定義成一個常量：NewsFunction.Draft

　　如果爲true就說明張三有起草新聞的權限。

　　當然對於web應用，您可以把Functions 用session保存起來，以避免每打開一個頁面都去數據庫中獲取。

　　似乎看起來是一個不錯的解決方案。

　　還是新聞系統，最初新聞系統沒有分類，但是隨着新聞的增加，沒有分類的新聞看起來總是亂的，於是張三和李四給新聞添加了分類A、分類B，還是由張三負責起草，李四負責審覈，以後又添加了更多的分類，並且也增加了人手，這個時候就有新的要求出來了：希望張三隻負責分類A的起草，分類B的起草交給其他人做，李四呢也只負責分類A的審覈（就相當於是一個欄目的責任編輯）。

 

權限設計（二）

樣的需求，版本一就無能爲力了（當然你也可以增加幾個功能：比如分類A的新聞起草和分類B的新聞起草，再把這個功能添加到相應的角色裏面去，但是這個應該不是我們要得解決方案吧，不過版本二也是基於這個思想來解決的）。

其實比新聞更好的例子是論壇板塊的版主。

下面是版本二的解決方案：

在版本二的功能表中加入了一個ResourceType這個字段，這個字段用來表示對某個資源的分類（比如新聞），我們同樣來模擬一下（新聞分類A的ResourceType爲：NTA，分類B爲：NTB）：

功能表：

FunctionID	ResourceType	FunctionName
F1	NTA	起草新聞：分類A
F2	NTA	編輯新聞：分類A
F3	NTA	審覈新聞：分類A
F4	NTA	刪除新聞：分類A
F1	NTB	起草新聞：分類B
F2	NTB	編輯新聞：分類B
F3	NTB	審覈新聞：分類B
F4	NTB	刪除新聞：分類B

然後在角色表添加相應的角色，在角色功能表中添加對應的功能。

獲取Functions的語句也相應地做變化：

Select FunctionID  + ‘，’ + ResourceType From 角色功能表 Where RoleID In (Select RoleID From 用戶角色表 Where UserID=’U1’)

權限的判斷也就變成：

Functions.Contain(‘F1,NTA’);

在新添加一個分類的時候，同時也在功能表中增加相應的記錄（當然不是在數據庫裏面直接添加，由和功能相關的函數來添加）。

使用這種解決方案可以簡單地對有分類的應用（比如論壇系統）的每個分類實行不同的控制（比如VIP板塊，就只能擁有VIP角色的用戶才能瀏覽、發表等，而其他板塊只要是註冊用戶就可以使用了）。

在實際應用中FunctionID並不是隨便的一個字符串，而是進行了編碼，其編碼中包含了模塊ID以及能夠體現出父子關係，舉個例子來說：對於論壇系統，我們給它一個模塊ID爲”30”，論壇的功能我們先分成2類，一類是管理類（比如刪除帖子），一類是使用類（比如發帖、回帖、瀏覽帖子等），給管理類一個編碼：01，使用類一個編碼：02，我們就對FunctionID進行如下的編碼：

300101：刪除帖子

300201：發帖

300202：回帖

300203：瀏覽帖子

對於資源（比如某個板塊1，板塊的ID爲：01），我們可以組合出如下的Functions（當然這個組合你也可以不用逗號分隔，用其他的組合方式也可以，不過不要產生歧義）：

300101,01：板塊1刪除帖子的功能

300201,01：板塊1發帖的功能

……

    對於RoleID也是採用的編碼方式，也能體現角色的父子關係，也可以實現角色功能的繼承等（當然獲取角色功能列表的SQL語句就不是現在這麼簡單了）。在我現在的應用裏面沒有實現角色的繼承（雖然角色的編碼體現出了角色的父子關係）。

 

 

 

 

 

公司概述

上海互聯網軟件有限公司由直屬科技部的國家火炬互聯網創業中心技術應用服務中心轉制而來。該機構爲科技部863火炬計劃之一，其宗旨在於探索以互聯網爲代表的新經濟在中國的成長與發展之路。公司以"服務於政府信息化建設"爲使命，致力於"做專業的電子政務系統軟件提供商，全力打造信息時代政府辦公新模式"。由於公司背景上的優勢，和幾年來在電子政務領域的不斷努力，使公司積累了一系列適合政府部門實際應用的系統設計和業務流程設計方面的經驗。

商業挑戰

隨着信息化建設的推進，各區縣的信息化水平正在不斷提升。截至目前，在各區縣的信息化環境中已經建設了衆多的應用系統並投入日常的辦公使用，這些應用系統已經成爲電子政務的重要組成部分。

各區縣的信息體系中的現存應用系統是由不同的開發商在不同的時期採用不同的技術建設的，如：郵件系統、政府內部辦公系統、公文管理系統、呼叫系統、GIS系統等。這些應用系統中，大多數都有自成一體的用戶管理、授權及認證系統，同一用戶在進入不同的應用系統時都需要使用屬於該系統的不同賬號去訪問不同的應用系統，這種操作方式不僅爲用戶的使用帶來許多不便，更重要的是降低了電子政務體系的可管理性和安全性。

與此同時，各區縣正在不斷建設新的應用系統，以進一步提高信息化的程度和電子政務的水平。這些新建的應用系統也存在用戶認證、管理和授權的問題。

在推進和發展電子政務建設的進程中，需要通過統一規劃和設計，開發建設一套統一的授權管理和用戶統一的身份管理及單點認證支撐平臺。利用此支撐平臺可以實現用戶一次登錄、網內通用，避免多次登錄到多個應用的情況。此外，可以對區域內各信息應用系統的權限分配和權限變更進行有效的統一化管理，實現多層次統一授權，審計各種權限的使用情況，防止信息共享後的權限濫用，規範今後的應用系統的建設。

爲此，我公司開發設計了統一用戶及權限管理系統1.0版，該系統以用戶爲中心，爲了確保用戶安全可靠的訪問相應的功能和信息，統一用戶及權限管理系統包含了統一用戶管理（UUM）子模塊來對註冊的用戶進行管理。統一用戶及權限管理系統在用戶組之間定義操作權限，定義用戶可以訪問哪些數據、哪些應用，支持用戶的單點登錄。

針對用戶的需求，爲了能夠滿足用戶在靈活性、可靠性、安全性以及效率等方面的要求，我公司設計出統一用戶及權限管理系統的完整系統框架，我們選擇了Microsoft Visual Studio.Net 作爲我們的開發工具，採用C#編程語言編寫asp.net web客戶端，作爲系統的展現層。

解決方案

系統介紹

統一用戶及權限管理系統的拓撲結構如下：

統一用戶及權限管理系統的邏輯結構如下：

該系統採用VS.Net體系結構，採用C#編程語言，Sql Server2000數據庫開發基於b/s結構的權限管理系統，該系統包括以下4個功能模塊，每個模塊又包含了幾個到十幾個不等的功能組，實現了權限管理所需的常用功能，其功能組成大致如下：

模塊	功能組
登錄頁	登錄頁
用戶授權管理	用戶基本信息管理、用戶包含的角色管理、用戶包含的權限管理、用戶組織機構管理、用戶崗位管理
組織機構管理	組織機構基本信息管理、崗位基本信息管理、崗位包含的權限管理、崗位認證管理、擁有崗位的用戶管理
應用權限定製	應用系統基本信息管理、應用系統權限組管理、應用系統權限管理、應用系統角色管理
系統維護	查詢系統審計、查詢應用審計

系統界面實例

首頁

新增用戶

用戶查詢

設置用戶角色

本系統的開發工作從2003年11月中旬到2004年2月底，耗時3個月，由五位工程師參與此項工作，到2月底已基本完成了系統的開發，從3月初開始，已在徐彙區現場實施，在現場實施過程中，並在實施的過程中針對用戶的管理思路，對系統作了一定的調整，進一步完善了系統，目前，系統已經在徐彙區得到了很好的應用。

 

商業收益

1.	增強的性能：ASP.NET 是在服務器上運行的編譯好的公共語言運行庫代碼。與被解釋的前輩不同，ASP.NET 可利用早期綁定、實時編譯、本機優化和盒外緩存服務。這相當於在編寫代碼行之前便顯著提高了性能。
2.	世界級的工具支持：ASP.NET 框架補充了 Visual Studio 集成開發環境中的大量工具箱和設計器。WYSIWYG 編輯、拖放服務器控件和自動部署只是這個強大的工具所提供功能中的少數幾種。
3.	威力和靈活性：由於 ASP.NET 基於公共語言運行庫，因此 Web 應用程序開發人員可以利用整個平臺的威力和靈活性。.NET 框架類庫、消息處理和數據訪問解決方案都可從 Web 無縫訪問。ASP.NET 也與語言無關，所以可以選擇最適合應用程序的語言，或跨多種語言分割應用程序。另外，公共語言運行庫的交互性保證在遷移到 ASP.NET 時保留基於 COM 的開發中的現有投資。
4.	簡易性：ASP.NET 使執行常見任務變得容易，從簡單的窗體提交和客戶端身份驗證到部署和站點配置。例如，ASP.NET 頁框架使您可以生成將應用程序邏輯與表示代碼清楚分開的用戶界面，和在類似 Visual Basic 的簡單窗體處理模型中處理事件。另外，公共語言運行庫利用託管代碼服務（如自動引用計數和垃圾回收）簡化了開發。
5.	可管理性：ASP.NET 採用基於文本的分層配置系統，簡化了將設置應用於服務器環境和 Web 應用程序。由於配置信息是以純文本形式存儲的，因此可以在沒有本地管理工具幫助的情況下應用新設置。此"零本地管理"哲學也擴展到了 ASP.NET 框架應用程序的部署。只需將必要的文件複製到服務器，即可將 ASP.NET 框架應用程序部署到服務器。不需要重新啓動服務器，即使是在部署或替換運行的編譯代碼時。
6.	可縮放性和可用性：ASP.NET 在設計時考慮了可縮放性，增加了專門用於在聚集環境和多處理器環境中提高性能的功能。另外，進程受到 ASP.NET 運行庫的密切監視和管理，以便當進程行爲不正常（泄漏、死鎖）時，可就地創建新進程，以幫助保持應用程序始終可用於處理請求。
7.	自定義性和擴展性：ASP.NET 隨附了一個設計周到的結構，它使開發人員可以在適當的級別"插入"代碼。實際上，可以用自己編寫的自定義組件擴展或替換 ASP.NET 運行庫的任何子組件。實現自定義身份驗證或狀態服務一直沒有變得更容易。
8.	安全性：藉助內置的 Windows 身份驗證和基於每個應用程序的配置，可以保證應用程序是安全的。