一、概要
通常,需要單獨(dú)的權(quán)限系統(tǒng)是解決授權(quán)的管理和維護(hù),再分配等難題,不針對開發(fā)而言。
系統(tǒng)架構(gòu)目標(biāo):在易于理解和管理,開發(fā)的前提下,滿足絕大部分粗粒度和細(xì)粒度權(quán)限控制的功能需要。
除了粗粒度權(quán)限,系統(tǒng)中必然還會包括無數(shù)對具體Instance的細(xì)粒度權(quán)限。這些問題,被留給對框架的擴(kuò)展方法來解決,這樣的考慮基于以下兩點(diǎn):
? 1、細(xì)粒度的權(quán)限判斷必須要在資源上獲取權(quán)限分配的支持的上下文信息才可能得以實(shí)現(xiàn)。
2、細(xì)粒度的權(quán)限常常具有相當(dāng)大的業(yè)務(wù)邏輯相關(guān)性。對不同的業(yè)務(wù)邏輯,常常意味著完全不同的權(quán)限判定原則和策略。相比之下,粗粒度的權(quán)限更具通用性,將其實(shí)現(xiàn)為一個架構(gòu),更有重用價值;而將細(xì)粒度的權(quán)限判斷實(shí)現(xiàn)為一個架構(gòu)級別的東西就顯得繁瑣,增加架構(gòu)的復(fù)雜性。而且不是那么的有必要,用定制的代碼來實(shí)現(xiàn)就更簡潔,更靈活。否則會變成各種邏輯代碼的堆砌。
比如,product post數(shù)量的控制,這種一般要知道用戶個性化的信息,付錢數(shù)量到數(shù)據(jù)庫中查找最高數(shù)量,還要知道此用戶已經(jīng)有多少產(chǎn)品等,規(guī)則不具備通用性和重用性,
?? 所以細(xì)粒度控制不應(yīng)該放在權(quán)限架構(gòu)層來解決。實(shí)例級的細(xì)粒度權(quán)限的解決方案就是將它轉(zhuǎn)化為粗粒度權(quán)限,這樣我們權(quán)限客戶端就變得很簡單了。
名詞解釋:
??? 粗粒度權(quán)限 :一般可以通過配置文件來授權(quán),授權(quán)只有真假,沒有多少之分,不需要上下文的支持。
??? 不消耗資源的。
??? 邏輯表達(dá)式:判斷“Who對What(Which)進(jìn)行How的操作”的邏輯表達(dá)式是否為真。
??? 別名:靜態(tài)授權(quán)、類級授權(quán)
?細(xì)粒度權(quán)限:不能通過配置文件等表達(dá),需要特定上下文的支持.
??? 邏輯表達(dá)式:判斷“When(Where)的時候,Who對What(Which)進(jìn)行How的操作”的邏輯表達(dá)式是否為真。
??? 別名:動態(tài)授權(quán)、實(shí)例級授權(quán)
設(shè)計(jì)原則 :
框架只提供粗粒度的權(quán)限。
細(xì)粒度的權(quán)限也需要集中管理和維護(hù)
細(xì)粒度的權(quán)限通過定制的擴(kuò)展代碼將細(xì)粒度轉(zhuǎn)化為粗粒度授權(quán)。
二、權(quán)限系統(tǒng)的設(shè)計(jì)
權(quán)限往往是一個極其復(fù)雜的問題, 設(shè)計(jì)權(quán)限系統(tǒng)第一個要解決的問題就是什么樣的行為是需要權(quán)限控制,什么樣的是業(yè)務(wù)方法。他們之間本來是沒有明確的區(qū)分,任何權(quán)限從某種角度上說可以是一種業(yè)務(wù)方法。為了以后管理和開發(fā)方面我們從概念上需要將權(quán)限和業(yè)務(wù)明確劃分清楚,指導(dǎo)開發(fā)。
?權(quán)限控制行為:? 對What(Which)進(jìn)行How的操作需要區(qū)分Who,具有Who身份差異性和可替換性。? 我們將此類操作作為權(quán)限。
???? 特點(diǎn): 可以收回也可以分配的,具有一定的抽象級別。?????? 消耗資源,行為結(jié)果具備一些持久性的影響。
?業(yè)務(wù)邏輯行為:? 對What(Which)進(jìn)行How的操作的時候與Who的身份無關(guān)或者具有Who身份差異性但???????????? 是不具有可替換性。
??? 特點(diǎn): 不能抽象和共享,很難回收和分配。不消耗資源,不產(chǎn)生持久性。現(xiàn)實(shí)中也存在某一時期行為是業(yè)務(wù)邏輯,最后演變成權(quán)限控制,或者相反的過程。
1、粗粒度權(quán)限設(shè)計(jì)
?????? 采用自主型訪問控制方法,操作給予訪問控制列表。每一個用戶通過角色獲得一組權(quán)限集合,權(quán)限系統(tǒng)的功能是驗(yàn)證用戶申請的權(quán)限(集合)是否在這個集合當(dāng)中,即申請的權(quán)限(集合)是否投影在用戶擁有的權(quán)限集合,換句話說:只要某用戶直接或者間接的屬于某個Role那么它就具備這個Role的所有權(quán)限許可。
一個自主型訪問控制方法的權(quán)限系統(tǒng)包括以下幾個部分:角色、權(quán)限、訪問控制表、
l???????? 權(quán)限
描述一個權(quán)限可以通過以下幾個要素說明:
類型(class):
名稱(name):
動作(actions):
掩碼(mask):
屬性:
具體權(quán)限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)配置
存取控制項(xiàng)(ACE):角色到權(quán)限的映射集合,表示某個角色可以在某些資源上執(zhí)行某些動作,它們之間通過role關(guān)聯(lián)(繼承),ACE之間產(chǎn)生包含關(guān)系。
存取控制列表(ACL):ACE的集合。
?我們的存取控制器(ACL)是通過一個xml的配置文件說明,存取控制列表由多個存取控制項(xiàng)(ACE)來描述。使用方法(略)
?2、細(xì)粒度權(quán)限設(shè)計(jì)
??? 細(xì)粒度授權(quán)需要上下文的支持,而且每個權(quán)限控制的上下問題都不一樣,這由相關(guān)的業(yè)務(wù)邏輯決定,而且此類授權(quán)一般變化較快,應(yīng)此需要將強(qiáng)的可維護(hù)性和擴(kuò)展性,支持變化,但又不能夠太復(fù)雜,否則缺乏可執(zhí)行性。雖然此類權(quán)限個性化較強(qiáng),我們?nèi)匀豢梢钥偨Y(jié)出很多共性:
1.?????? 幾乎所有的授權(quán)需要用戶的角色和ID.
2.?????? 特定的上下文幾乎都同用戶資源使用情況相關(guān).
?? 我們將此類信息稱為UserState 即:User角色以及資源使用情況和當(dāng)前狀態(tài)。大部分信息我們在用戶登陸的時候已經(jīng)。獲得。授權(quán)貫穿Web層和Biz層,因此我們的登陸要獨(dú)立于Web端。因此上下文我們可以用UserState結(jié)合其他來抽象。
?? 關(guān)于上下文的維護(hù)問題,我們不可能將UserState此類參數(shù)在Web層和Biz層來回傳遞,更加不能在需要授權(quán)的地方都加上一個這樣的方法參數(shù),這樣不太現(xiàn)實(shí)。其次如果在授權(quán)的地方再從數(shù)據(jù)庫中取一次這樣雖然能夠解決部分問題(不能解決userId的傳遞),這樣效率太低,不能接受。
?????? 解決方法就是將此類信息cache起來,用的時候再去取,由于此類信息具有非常高的并發(fā)性,對線程安全較高,因此我們決定將此類信息放入一個線程上下文的內(nèi)存cache中。此外我們由于引入cache,就需要解決所有cache共有的維護(hù)性問題。
?????? Cache的生命周期:用戶的一次請求,屬于線程級,用戶請求線程結(jié)束,Cache結(jié)束。
?????? Cache的更新:當(dāng)上下文信息發(fā)生變化是需要及時更新Cache,這是一個不可避免的步驟。
??????? Cache丟失:發(fā)生在如系統(tǒng)down機(jī),線程崩潰,內(nèi)存溢出等等,對用戶來說就是當(dāng)前請求突然中斷。
?????? 當(dāng)用戶重新發(fā)送請求,我們的系統(tǒng)就需要重新驗(yàn)證用戶,此時我們可以更新Cache解
?????? 決丟失問題。
?????? Cache的清理:這個實(shí)現(xiàn)就是當(dāng)用戶請求結(jié)束,返回應(yīng)答的時候清理,可以通過Filter實(shí)現(xiàn),比較簡單。
以上是相關(guān)的原理部分,我們看看系統(tǒng)地實(shí)現(xiàn):
實(shí)現(xiàn):線程上下文的cache
實(shí)現(xiàn)類: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()