java許可權設計探討–釋放使用者特權(初篇)

     許可權設計對於系統來說是一套資源防禦系統，避免不同使用者種類越權使用。這幾天看了一些許可權設計設計，但還是感覺他們似乎還是有點欠缺，首先我比較關注RBAC，RBAC提供3套許可權設計模式。
    首先看第一種RBAC0,RBAC0 定義了能構成一個RBAC控制系統的最小的元素集合，這種模式是早期業界非常普遍的模式，讓使用者關聯角色，角色群組合多個許可權資源。但現在的業務越來非常，要求人性化更多一點，設計更合理些，加入使用者需要超越自己所在的角色擴充其他的許可權，就會帶來很大困難的擴充。
    RBAC1,RBAC1 引入角色間的繼承關係.這個突破帶來了角色之間的繼承關係，從而讓一個使用者由可以充當多種角色。可以說這是許可權發展史上的一種趨勢。
    但總體來看，RBAC沒有讓使用者，角色和許可權之間得到很好的整合，大多還是困在使用者這裡，試想，如果使用者擁有的角色其實可以充當一個中許可證，一個使用者有可以擁有多張許可證，這是理所當然的事，然能否再用一個對指定資源特殊的許可證呢？這就是我想的使用者既然可以擁有角色，但同樣也可以擁有指定的一些許可權，這種而外分配的許可權可以說是這個使用者的特權（注意，不是角色，因為擴充角色特權那就讓其他擁有此角色的使用者同時擁有，這樣的做法不是我所要討論的擴充）。好了，如果形成這樣的關係，就可以釋放使用者與角色之間的強捆綁了。
    但我還是覺得這樣做是否合理，一個模組和多個操作，形成了一資源，這些資源是被保護的，如果添加模組，就要配置這些資源，但添加的模組又不可能在動作表名的動作都有，這樣又要添加操作類型，許可權驗證的時候又需要到關係庫中檢查一下，其實，我覺得一個模組對應的操作不該由模組表和操作類型表配置來決定，因為他們可能是一個模組特有，這中間可能包括了許可權繼承關係，比如一個使用者模組許可權有read,add,modify,delete,query,all,注意這個ALL許可權一旦有用，這會包含他所有的操作，有刪除會有讀取，這樣當我們給與刪除許可權的時候其實read許可權也就包含進去了，現在有一個管理員管理模組許可權有read,add,modify,delete,query,reset_password,modify_password,all,定這些操作應為設計到管理員相關的操作，我們看這個模組比使用者模組多了2個許可權，這些特殊的許可權應該是配置，這種許可權繼承關係也應該是定製的，網上發布的2的N此方整數組成的集合，素數分解等都是不錯的許可權繼承辦法。那是不是讓我們在系統中擴充這些類就可以了列？是的，這樣做的好處有：1.避免後台資源配置錯誤導致許可權驗證出現問題；2.擷取管理員所有許可權後直接在web層驗證；3.可以設計自己的許可權繼承演算法。
    說到這裡，為什麼說這個問題呢，因為我的主題是JAVA許可權，JAVA已經提供了sucrity包，別忘了還有annotation。它可以幫我們條用指定方式的時候去用哪個定製的權限類別去做驗證。這樣一來許可權的問題可以得到靈活的擴充了，可能現在在這裡一時無法說完整，但這個JAVA許可權設計我已經開始設計，在設計完後希望和大家繼續探討。