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