通常所說的權限實際是由兩個部分組成:Resource(資源) + Access(操作方式).比如說創建目錄,
刪除目錄,查看目錄,這里的目錄就是系統中的資源,是需要受保護的,而創建,刪除和查看這些屬于操作方
式.
權限系統中的權限可以分為粗粒度和細粒度兩種,粗細粒度的區分的依據是資源.如果權限控制需
要針對資源的具體實例,那么這個權限就是細粒度的,否則就是粗粒度的.比如這里的查看目錄權限就是一
個粗粒度的權限,而查看某個具體目錄的權限即屬于細粒度的權限.
細粒度的權限往往是和用戶邏輯相關的,所以這不應該把它當作權限系統的一部分,而應當作用戶
邏輯的一部分來處理.這樣權限系統的設計易于理解,也便于實現.
Resource和Access的管理可以由兩種方式來處理,一種是已經由系統預先定義好的,一種是有可以
有用戶自己添加和組合,
后一種處理方式比較麻煩(無論對于用戶和程序員來說),適合與應用比較復雜的場合.對于我們的
系統可以考慮預定義的方式
比如可以設置一個Permisson表,權限可以有:添加Category,添加Item,添加用戶等等.
下面是Rescouce和Access組合的一個例子:
粗粒度:
Category Add
Edit
Delete
view
Item Add
Edit
Delete
view
User Add
Edit
Delete
view
細粒度:
張三的ategroy Add
Edit
Delete.
view
2.Role
權限的載體和分配單位,也是權限的集合.通常系統中權限都分配給Role.再把Role分配個User.這
由Role來作為User和權限的紐帶.這樣做是因為用戶和角色之間的關系是容易變化的,而系統中一個角色的
權限通常是穩定不變的. Role對系統的貢獻實質上就是提供了一個比較粗顆粒的分配單位
角色直接進行可以繼承,孩子擁有父親所有的權限.
如果系統中有User Group,有時也會把Role分配給User Group或者直接把權限分配給User Group,
此時Role也不是必需的.當用戶加入到這個Group的時候,也就擁有了這個Group的權限.
3.User Group
通常定義成User的集合.我覺得權限系統引進User Group基于兩種需求:
A. 需要以組的形式對某些具體的資源進行細粒度的權限控制(比如我創建的記錄可以給同組的人
看和編輯)
Group中的User具有的角色和權限可以不一樣.他們被分到一個組中的原因只是因為某些具體的資源.在這
個Group中,具有相同角色的User對于這個Group擁有的具體資源具有一樣的訪問能力.
在這里,User Group也不是必需的,比如可以通過增加細粒度的權限和角色來實現.例如:管理員為
我的這個記錄增加讀寫權限,添加相應的角色,分配給不同的用戶,那么他們也就擁有了對于這個記錄不同
的權限.我每添加一條記錄,就要做上述的操作,這樣是不是很麻煩?
如果用User Group的話,那么管理員可以創建一個分組,把我和其他的用戶分到一個組.具有記錄
訪問權限的用戶想要訪問我的記錄只需要判斷是否和我同組就可以了.但是由于User 和 User Group是多
對多的關系,那么這樣的判斷邏輯就會有一個問題:就拿我們要做的系統來說:
SystemAdmin 創建六個CP(Content Provider): A,B,C,D,E,F
創建3個地域(這里可以看作是Group): 北京,天津,上海
分配:
A,B==>北京
A,C,D==>天津
E,F==>上海
A,B具有相同的權限(都是CP),A可以管理北京和天津的內容.這沒有問題,問題是如何判斷B不可以
管理天津的內容呢?當B要訪問天津的信息,如果僅僅判斷B是否和A同組,那么這里的邏輯就會允許B也能夠
訪問天津的信息.要避免這種情況,我想為這些具體資源除了創建者的信息外,還需要記錄這些具體資源所
屬的組(比如用一張Category-Group表來記錄),這和創建者所屬的組的有關系.
比如A在創建信息的時候,他就可以選擇發布到北京或者天津去.而C要創建信息,只能發布到天津
去.也就是這個記錄所從屬的組是天津.這樣的話,那么當要決定B是否能訪問天津的信息時,判斷是否在這
個具體資源所在的組里就可以了.具體的判斷如下
B是CP嗎?
是-->B和要訪問的信息是同組嗎?
是-->允許訪問
否-->拒絕
否-->拒絕
引入User Group的另外一個例子:
假設有幾個用戶具有不同的權限,職位也不一樣,但是有一天需要他們共同合作一個項目,那么可
以為這些用戶新建立一個用戶組,并把該項目分配到這個用戶組就可以了.在這個需求中,用戶的權限沒有
變化,部門也沒有變化,所變化的是這些用戶擁有了對于這個具體項目的控制權.管理員所做的只是把這些
用戶放入一個組.一旦項目完成刪除這個用戶組就可以了.
有了組的概念后系統可以做的更加靈活,但是也會相對復雜.
B. 需要對User進行資源權限意義上的分組
從這個角度上進行的分組,通常一個分組中的User所具有的權限是一樣的,比如有超級管理員組,
模塊管理員組,用戶組之類.
在引入這種類型的組的時候,Role不再分配給用戶,而直接分配用給User Group.有的系統實現甚
至取消了Role,直接把權限分給User Group,把它作為了權限的載體.另外組可以繼承組,組的孩子擁有父親
的Role和權限.當把用戶加入到User Group,那么這個用戶也就擁有了這個Group的Role和權限.此時,User
Group和Role 其實所起的作用有些重疊,或者從另外一個意義講,User Group就是換了名字的Role而已.
有些系統的使用更為復雜,Role 和 group同時存在,Role既可以給User,也可以給User Group,一
個Group中的用戶所扮演的Role也不一樣,用戶可以和具體的資源進行權限聯系,也可以由Group來進行聯系
,這種系統的靈活性很高,但是對于管理員的要求也同樣很高.
User Group的概念我覺得比較靈活,實際應用中如何使用還是得取決于系統的需求.
另外要注意權限的疊加問題.比如給某個用戶分配了一個粗粒度的權限(比如Category Add),那么此時用
戶就擁有在任何地方添加Categoy的權限.但是隨后又把他加入到了一個組,這個組是和具體的資源聯系的,
那么這個時候這個用戶實際上權限受到了限制,他只能夠在這個組所聯系的資源中添加Caetgory.