許可權設計
B/S系統中的來許可權比自C/S中的更顯的重要，C/S系統因為具有特殊的客戶端，所以訪問用戶的許可權檢測可以通過客戶端實現或通過客戶端+伺服器檢測實現，而B/S中，瀏覽器是每一台計算機都已具備的，如果不建立一個完整的許可權檢測，那麼一個「非法用戶」很可能就能通過瀏覽器輕易訪問到B/S系統中的所有功能。因此B/S業務系統都需要有一個或多個許可權系統來實現訪問許可權檢測，讓經過授權的用戶可以正常合法的使用已授權功能，而對那些未經授權的「非法用戶」將會將他們徹底的「拒之門外」。下面就讓我們一起了解一下如何設計可以滿足大部分B/S系統中對用戶功能許可權控制的許可權系統。
㈡ 誰能說說許可權是如何設計的
許可權設計目前為止都沒有一個最完美的設計，只有一個最適合的設計
比如WINDOWS,本身設計也就是到了角色的級別，如果WINDOWS許可權能夠控制到文件，文件夾，甚至是文件的某一行，相反還太過繁瑣，屬於設計過度。
在軟體開發中,為軟體加入許可權控制功能,使不同的用戶有不同的使用權限,是非常重要的一項功能,由其在開發資料庫方面的應用,這項功能更為重要。一般均以菜單訪問功能的形式出現,按照常規的做法,只要讓注冊進入應用的不同用戶,可以訪問不同的功能菜單,從而實現功能許可權的控制,但是,有這樣一個問題,此種方法便無能為力,現在的應用軟體,為了提高軟體的易操作性,同一功能可能有多種不同的訪問方式,如工具條,右鍵菜單等；同樣,同一個功能,也可能在軟體的不同地方被調用,而不僅僅被限制為用程序的主菜單來調用,這樣,才能保證應用的易用性。
目前使用的比較多的設計方法一般是基於角色的，即
用戶——角色——許可權
判斷一個用戶有沒有許可權做某件事情，先判斷該用戶所屬的角色，然後查看該角色的許可權，通過查找出來的許可權，來判斷該用戶能否進行操作。
資料庫的設計可以參考以下：
http://www.cnblogs.com/wuhuacong/archive/2009/06/19/1507065.html
㈢ 有關設計代表許可權的規范。
兩個人要是都拍不了板，那就找能拍板的人啊。
㈣ 誰能提供一個關於用戶角色許可權設計完整的方案。謝謝
User：用戶表，存放用戶信息
Role：角色表，存放角色信息
UserInRole：用戶角色映射表，存放用戶和角色的對就關系，多對多，一個用戶可以對應多個
角色，而不同的角色有一同的許可權。
Permissions：許可權表，不同的角色對應不同的許可權。許可權信息使用一個欄位flag來表示，
好處是可以使用位運算來計算許可權，缺點是用位標識的許可權受理論值限制，如int理論上可以
標識31種不同的許可權, 當然可以整加一個欄位來彌補，ApplicationID標識不同的模塊
Application：模塊信息。
[Flags]
public enum Flag:long
{
View=1,
Edit=2,
Delete=4
}
特性[Flag]告訴編譯器,當編譯器看到Flag枚舉時，它會充許你用|(or)操作符組合枚舉值，
就像二的整數冪一樣，
例如 Flag Administer=Flag.View|Flag.Edit|Flag.Delete;表示三種許可權的組合。
基礎知識：
位運算
枚舉Flag
當編譯器看到Flag枚舉時，它會充許你用|(or)操作符組合枚舉值，
就像二的整數冪一樣，
例如 Flag Administer=Flag.View|Flag.Edit|Flag.Delete;
常用操作，檢查是否存在
Flag administer=Flag.View|Flag.Edit|Flag.Delete;
public bool Check(Flag administer,Flag mask)
{
bool bReturn = false;
if ((administer & mask) == mask)
bReturn = true;
return bReturn;
}
調用 Check(administer,Flag.Edit)將返回true.
public Flag SetBit(Flag administer,Flag mask)
{
return administer |= mask;
}
administer |= mask;操作相當於 administer = administer |mask;
從枚舉中減去一種狀態
administer &=mask;
如 :
Flag administer=Flag.View|Flag.Edit|Flag.Delete;
如需要禁止刪除許可權.
administer &=Flag.Delete;
另外，標記為flag的枚舉類型，可以不設置值
public enum Flag:long
{
View,
Edit,
Delete
}
如需要設置，按以下規律， View=1,Edit=2,Delete=4,Reply=8按2次方累加，為什麼會這樣？因為他使用二進制操作，
當你使用 View=1,Edit=2,Delete=3,Reply=4這樣的值， Flag.Delete 包含的值是Flag.Delete還是View=1|Edit=2就無從檢測了.
每個用戶，可以屬於不同的角色不同的角色分配不同的許可權，計算所有解權的所有可能的許可權組合，只要有充許的許可權，那麼該用戶既獲取該許可權。
在CS系統中，Permissions表合用了二個欄位來標識許可權.
AllowMask,DenyMask 規責是Deny優先,也就是說當許可權標記為Deny那麼不論是否Allow一律禁止該用戶進行此項操作。
另外，像論壇類的許可權設計，僅僅一個ApplicationID欄位是不夠用的，因為每個版塊都需要設置不同的許可權，來控制許可權的粒度，可在增加一張Permission表，ApplicationID修改為版塊ID
這樣，就可以針對不同的版塊設置不同的許可權
好了，接下的問題是怎麼和.net自帶的許可權系統掛鉤了。。
在asp.net系統中 ，HttpContext.Current.User實現了一個介面IPrincipal,IPrincipal包含了另一個介面Identity
我們在設計User類的時候繼承此介面
public class User:IPrincipal
{
string username;
public string Username
{
get{return username;}
set{username=value;}
}
}
實現IPrincipal介面方法
public IIdentity Identity
{
get {
if (!string.IsNullOrEmpty(username))
_Identity = new GenericIdentity(username,"Forums");
return (IIdentity)_Identity;
}
}
public bool IsInRole(string role)
{
.....
}
怎樣和asp.net掛鉤呢，這里可以在登陸時做檢查
if(HttpContext.Current!=null){
User u= Users.GetUser(name);
HttpContext.Current.User =u;
在使用時
User u = HttpContext.Current.User as User;
當然檢查用戶角色可以直接用
if(HttpContext.Current.User.Identity.IsAuthenticated&&HttpContext.Current.User.IsInRole(角色名))
另外可以直接把到當用戶許可權策略掛接到當前線程 ,使用以下方法
AppDomain.CurrentDomain.SetPrincipalPolicy(User);
好了，接下來，怎麼check許可權？
我傾向於使用Attribute
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method | AttributeTargets.Property | AttributeTargets.Delegate, Inherited = true, AllowMultiple = true)]
public class CheckPermissionAttribute : Attribute
{
int appID;
public int ApplicationID
{
get { return appID; }
set { appID = value; }
}
Permission _allMask;
public Permission AllMask
{
get { return _allMask; }
set { _allMask = value; }
}
public CheckPermissionAttribute(ApplicationID app, Permission allMask)
{
appID = app;
_allMask = allMask;
}
public CheckPermissionAttribute(Permission allMask)
{
_allMask = allMask;
}
}
AttributeUsage 第一個參數表示該屬性可以應用於類，方法，屬性，代理上
Inherited 檢查繼承的許可權。
AllowMultiple 充許多次應用。
按下來，設計一個基類,繼承自Page：
public class PageBase : Page
{
Flag _allMask;
/// <summary>
/// 檢查類型許可權
/// </summary>
public void CheckClass()
{
Type type = this.GetType();
CheckPermissionAttribute att = (CheckPermissionAttribute)CheckPermissionAttribute.GetCustomAttribute(type, typeof(CheckPermissionAttribute));
if (att != null)
{
Check(att.AllMask);
}
}
/// <summary>
/// 檢查函數調用許可權
/// </summary>
/// <param name="methodName">方法名</param>
public void CheckMethod(string methodName)
{
Type type = this.GetType();
string name = "*";
if (!string.IsNullOrEmpty(methodName))
name = methodName;
MemberInfo[] mis = type.FindMembers(MemberTypes.Method ,BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.IgnoreCase,Type.FilterNameIgnoreCase,name);
foreach (MethodInfo m in mis)
{
CheckPermissionAttribute att = (CheckPermissionAttribute)CheckPermissionAttribute.GetCustomAttribute(m, typeof(CheckPermissionAttribute));
if (att != null)
{
Check(att.AllMask);
}
}
return;
}
public void Check(Flag permissions)
{
if (!CheckPermission(permissions))
{
string url = string.Format("MsgPage.aspx?msg={0}", HttpUtility.UrlEncode("您沒有許可權訪問該資源"));
Response.Redirect(url);
}
}
public void Check(ApplicationID appID, Flag permissions)
{
PermissionManager pm= Spaces.PermissionManager.Instance(appType);
if (!CheckPermission(pm,permissions))
{
string url = string.Format("MsgPage.aspx?msg={0}", HttpUtility.UrlEncode("您沒有許可權訪問該資源"));
Response.Redirect(url);
}
}
protected override void OnInit(EventArgs e)
{
CheckClass();
base.OnInit(e);
}
}
如何使用：
[CheckPermission(2, Flag.View)]
public partial class MyPage : PageBase
{
}
若沒有查看許可權，會自運導向錯誤頁面。
在類上應用挺方便。
方法上應用我於一個方法比較麻煩，我還沒有找到在頁面class里怎麼獲取當前調用的類名.
可以調用 CheckMethod(方法名稱);如
[CheckPermission(2, Flag.Delete)]
public partial class MyPage : PageBase
{
public void test()
{
CheckMethod("test");
.......
}
}
㈤ javaweb 項目的系統許可權管理，怎麼設計
java web 項目來的系統許可權管理設計方法有兩自種：
方法一、SpringMVC整合Shiro （Shiro是強大的許可權管理框架）
參考：http://www.360doc.com/content/14/0529/09/11298474_381916189.shtml
方法二、基於角色的訪問許可權控制
基於角色的訪問許可權控制
首先基於角色的訪問許可權控制，所有的用戶訪問都會經過過濾，然後分析訪問許可權加以認證！許可權中的重點，表的設計。
普遍三張表，表名自定義。用戶表（User），角色表（Role），資源表（Resource）
用戶表沒有特別，很簡單。關鍵是角色表和資源表。
㈥ 如何設計用戶、角色、許可權表
用戶
:ID
UserName
角色與用戶關系表:ID
userID
RoleID
角色:ID
RoleName
角色與許可權項關版系表:ID
許可權項表ID
RoleID,Effectiveness
--顯示這許可權是否有效
許可權項表
ID
Name
----------------
同1樓一致，只是權多了Effectiveness
--顯示這許可權是否有效
㈦ 許可權系統設計
請你參考RBAC通用設計，這個是通用的，理解後實現簡單，不限語言
㈧ 許可權設計問題
一、概要
通常，需要單獨的許可權系統是解決授權的管理和維護，再分配等難題，不針對開發而言。
系統架構目標：在易於理解和管理，開發的前提下，滿足絕大部分粗粒度和細粒度許可權控制的功能需要。
除了粗粒度許可權，系統中必然還會包括無數對具體Instance的細粒度許可權。這些問題，被留給對框架的擴展方法來解決，這樣的考慮基於以下兩點：
1、細粒度的許可權判斷必須要在資源上獲取許可權分配的支持的上下文信息才可能得以實現。
2、細粒度的許可權常常具有相當大的業務邏輯相關性。對不同的業務邏輯，常常意味著完全不同的許可權判定原則和策略。相比之下，粗粒度的許可權更具通用性，將其實現為一個架構，更有重用價值；而將細粒度的許可權判斷實現為一個架構級別的東西就顯得繁瑣，增加架構的復雜性。而且不是那麼的有必要，用定製的代碼來實現就更簡潔，更靈活。否則會變成各種邏輯代碼的堆砌。
比如，proct post數量的控制，這種一般要知道用戶個性化的信息，付錢數量到資料庫中查找最高數量，還要知道此用戶已經有多少產品等，規則不具備通用性和重用性，
所以細粒度控制不應該放在許可權架構層來解決。實例級的細粒度許可權的解決方案就是將它轉化為粗粒度許可權，這樣我們許可權客戶端就變得很簡單了。
名詞解釋
粗粒度許可權：一般可以通過配置文件來授權，授權只有真假，沒有多少之分，不需要上下文的支持。不消耗資源的。
邏輯表達式：判斷「Who對What(Which)進行How的操作」的邏輯表達式是否為真。
別名：靜態授權、類級授權
細粒度許可權：不能通過配置文件等表達，需要特定上下文的支持.
邏輯表達式：判斷「When(Where)的時候，Who對What(Which)進行How的操作」的邏輯表達式是否為真。
別名：動態授權、實例級授權
設計原則：框架只提供粗粒度的許可權。細粒度的許可權也需要集中管理和維護，細粒度的許可權通過定製的擴展代碼將細粒度轉化為粗粒度授權。
二、許可權系統的設計
許可權往往是一個極其復雜的問題， 設計許可權系統第一個要解決的問題就是什麼樣的行為是需要許可權控制，什麼樣的是業務方法。他們之間本來是沒有明確的區分，任何許可權從某種角度上說可以是一種業務方法。為了以後管理和開發方面我們從概念上需要將許可權和業務明確劃分清楚，指導開發。
許可權控制行為： 對What(Which)進行How的操作需要區分Who，具有Who身份差異性和可替換性。 我們將此類操作作為許可權。
特點： 可以收回也可以分配的，具有一定的抽象級別。 消耗資源，行為結果具備一些持久性的影響。
業務邏輯行為： 對What(Which)進行How的操作的時候與Who的身份無關或者具有Who身份差異性但 是不具有可替換性。
特點： 不能抽象和共享，很難回收和分配。不消耗資源，不產生持久性。現實中也存在某一時期行為是業務邏輯，最後演變成許可權控制，或者相反的過程。
1、粗粒度許可權設計
採用自主型訪問控制方法，操作給予訪問控制列表。每一個用戶通過角色獲得一組許可權集合，許可權系統的功能是驗證用戶申請的許可權（集合）是否在這個集合當中，即申請的許可權（集合）是否投影在用戶擁有的許可權集合,換句話說：只要某用戶直接或者間接的屬於某個Role那麼它就具備這個Role的所有權限許可。
一個自主型訪問控制方法的許可權系統包括以下幾個部分：角色、許可權、訪問控製表、
（1）許可權
描述一個許可權可以通過以下幾個要素說明：
類型（class）:
名稱（name）：
動作(actions)：
掩碼（mask）：
屬性：
具體許可權Example:
1、Test
類型（class）:com.yangjs.secutiry. permissions. TestPermission
名稱（name）：如：test.* ，test.sub.* ,test.sub1.sub2
動作(actions)： brower_detail ,post,repost,……
掩碼（mask）：0x1,0x2,0x4…..
屬性： 無
.…………..
l 存取控制器（my--acl.xml）配置
存取控制項（ACE）：角色到許可權的映射集合，表示某個角色可以在某些資源上執行某些動作，它們之間通過role關聯（繼承），ACE之間產生包含關系。
存取控制列表（ACL）：ACE的集合。
我們的存取控制器（ACL）是通過一個xml的配置文件說明，存取控制列表由多個存取控制項（ACE）來描述。使用方法(略）
2、細粒度許可權設計
細粒度授權需要上下文的支持，而且每個許可權控制的上下問題都不一樣，這由相關的業務邏輯決定，而且此類授權一般變化較快，應此需要將強的可維護性和擴展性，支持變化，但又不能夠太復雜，否則缺乏可執行性。雖然此類許可權個性化較強，我們仍然可以總結出很多共性：
（1） 幾乎所有的授權需要用戶的角色和ID.
（2） 特定的上下文幾乎都同用戶資源使用情況相關.
我們將此類信息稱為UserState 即：User角色以及資源使用情況和當前狀態。大部分信息我們在用戶登陸的時候已經。獲得。授權貫穿Web層和Biz層，因此我們的登陸要獨立於Web端。因此上下文我們可以用UserState結合其他來抽象。
關於上下文的維護問題，我們不可能將UserState此類參數在Web層和Biz層來回傳遞，更加不能在需要授權的地方都加上一個這樣的方法參數，這樣不太現實。其次如果在授權的地方再從資料庫中取一次這樣雖然能夠解決部分問題（不能解決userId的傳遞），這樣效率太低，不能接受。
解決方法就是將此類信息cache起來，用的時候再去取，由於此類信息具有非常高的並發性，對線程安全較高，因此我們決定將此類信息放入一個線程上下文的內存cache中。此外我們由於引入cache，就需要解決所有cache共有的維護性問題。
Cache的生命周期：用戶的一次請求，屬於線程級，用戶請求線程結束，Cache結束。
Cache的更新：當上下文信息發生變化是需要及時更新Cache，這是一個不可避免的步驟。
Cache丟失：發生在如系統down機，線程崩潰，內存溢出等等，對用戶來說就是當前請求突然中斷。
當用戶重新發送請求，我們的系統就需要重新驗證用戶，此時我們可以更新Cache解決丟失問題。
Cache的清理：這個實現就是當用戶請求結束，返回應答的時候清理，可以通過Filter實現，比較簡單。
以上是相關的原理部分，我們看看系統地實現：
實現：線程上下文的cache
實現類：com.yangjs.cache.ThreadContextCache:
public class ThreadContextCache {
public static Map asMap()；
public static boolean containsKey(Object key)；
public static boolean containsValue(Object key)；
public static Object get(Object key)；
public static void put(Object key, Object value)；
public static Object remove(Object key)；
public static void clean()；
public static int size() ；
public static void destroy()
㈨ 關於許可權設計
欄位可以設置成抄角色、功能模塊、許可權襲標志
每個功能模塊為一條記錄 然後許可權標志假定為1和0 ，1為可以進入0為不可進入
進入的時候Select * From 表Where 角色 = '當前角色'And功能模塊='要進入的功能模塊名稱' 如果 許可權標志為1允許為0則不允許
或者進入的時候Select * From 表Where 角色 = '當前角色' And 功能模塊='要進入的功能模塊名稱' And 許可權標志 = '1' 如果查詢到的記錄數大於0 則允許進入
㈩ 用戶許可權設計
基於角色的訪問控制模型就是把「用戶—角色—操作—資源」關聯到一起，實現非自主型訪問控制策略。使用基於角色的訪問控制模型可以減輕安全管理工作，因為某種任務是穩定的，而負責該項任務的人員是經常變化的，這種方式只需把新的用戶分配給已有的角色即可，無需為用戶重新指定資源和操作，因而簡化了授權管理工作。
為了保障本系統操作使用的信息安全，系統登錄認證體系由三個要素組成:用戶、角色、許可權，三者相輔相成，共同組成系統的安全運行屏障。
1.用戶信息
用戶信息表統一管理，在用戶信息表中存儲用戶名稱、登錄名、口令、各子系統許可權、用戶角色信息等。
用戶信息表的添加、刪除以及子系統許可權修改由總系統授權的管理員執行，本系統中，用戶信息表的操作在業務處理與信息服務子系統的系統管理菜單下的用戶信息管理頁面。用戶口令可以自行改變，用戶許可權的變更需要提請管理員同意，並由管理員修改。
子系統啟動時讀取用戶信息表驗證用戶許可權，在系統運行時依據許可權分配相應的功能。依據用戶在子系統中的許可權級別控制用戶可操作的功能，實現最終用戶對ORACLE資料庫中數據的讀取和添加操作許可權控制(表8－2)。
表8－2 用戶信息結構表
2.角色信息
角色可以根據需要任意多地添加，多個角色許可權組合生成多個許可權控制，對應到一個確定的用戶，賦予用戶對功能模塊的控制許可權。用戶角色表包括角色名稱、用戶唯一值編碼等信息。示例見表8－3。
表8－3 用戶角色表(示例)
在資料庫中為各個功能模塊建立了功能名稱表，每個功能模塊均有記錄，有功能編碼和功能名稱及其他附屬信息。功能名稱示例見表8－4。
表8－4 功能名稱表(示例)
每個用戶必須屬於至少一個角色，每個角色具備多個功能的控制許可權，功能許可權通過角色傳遞給用戶，從而實現用戶對功能的操作許可權控制。
3.許可權信息
許可權表明了用戶可執行的操作。系統許可權控制採用最大優先，用戶可以擁有多個角色，每個角色對每一頁面都可擁有許可權，但在許可權結果判斷時只以最大許可權為主，即管理員級許可權大於並包含訪問者許可權。功能許可權示例如表8－5所示。
表8－5 功能許可權表(示例)
系統規劃的子系統許可權等級見表8－6。
表8－6 子系統許可權等級規劃表(部分)
續表
4.用戶認證授權
通過以上四個表將用戶、角色與許可權組合起來，可以形成無窮多的用戶許可權組合，直接控制用戶許可權到每個細分功能。
用戶、角色、許可權、功能控制流程如圖8－1所示:
圖8－1 用戶許可權控制流程圖
功能許可權表僅在部署角色許可權時使用，標示功能具備的可部署許可權。
在角色中必須保證有一個管理角色擁有用戶管理功能的管理許可權，防止不能分配角色與許可權，同樣在用戶中必須保證至少有一個用戶是管理角色。