只要有用戶參與的系統通常都要有權限管理,權限管理實現對用戶訪問系統的控制,按照安全規則或者安全策略控制用戶能夠訪問並且只能訪問本身被受權的資源。java
權限管理包括用戶認證和受權兩部分。安全
用戶認證,用戶去訪問系統,系統要驗證用戶身份的合法性。最經常使用的用戶身份驗證的方法:一、用戶名密碼方式、二、指紋打卡機、三、基於證書驗證方法。。系統驗證用戶身份合法,用戶方可訪問系統的資源。htm
subject:主體,理解爲用戶,多是程序,都要去訪問系統的資源,系統須要對subject進行身份認證。對象
principal:身份信息,一般是惟一的,一個主體還有多個身份信息,可是都有一個主身份信息(primary principal)ip
credential:憑證信息,能夠是密碼 、證書、指紋。ci
總結:主體在進行身份認證時須要提供身份信息和憑證信息資源
用戶受權,簡單理解爲訪問控制,在用戶認證經過後,系統對用戶訪問資源進行控制,用戶具備資源的訪問權限方可訪問。開發
受權的過程理解爲:who對what(which)進行how操做。get
who:主體即subject,subject在認證經過後系統進行訪問控制。權限控制
what(which):資源(Resource),subject必須具有資源的訪問權限纔可訪問該 資源。資源好比:系統用戶列表頁面、商品修改菜單、商品id爲001的商品信息。
資源分爲資源類型和資源實例:
系統的用戶信息就是資源類型,至關於java類。
系統中id爲001的用戶就是資源實例,至關於new的java對象。
how:權限/許可(permission) ,針對資源的權限或許可,subject具備permission訪問資源,如何訪問/操做須要定義permission,權限好比:用戶添加、用戶修改、商品刪除。
主體(帳號、密碼)
資源(資源名稱、訪問地址)
權限(權限名稱、資源id)
角色(角色名稱)
角色和權限關係(角色id、權限id)
主體和角色關係(主體id、角色id)
一般企業開發中將資源和權限表合併爲一張權限表,以下:
資源(資源名稱、訪問地址)
權限(權限名稱、資源id)
合併爲:
權限(權限名稱、資源名稱、資源訪問地址)
上圖常被稱爲權限管理的通用模型,不過企業在開發中根據系統自身的特色還會對上圖進行修改,可是用戶、角色、權限、用戶角色關係、角色權限關係是須要去理解的。
RBAC(role based access control),基於角色的訪問控制。
好比:
系統角色包括 :部門經理、總經理。。(角色針對用戶來劃分)
系統代碼中實現:
//若是該user是部門經理則能夠訪問if中的代碼
if(user.hasRole('部門經理')){
//系統資源內容
//用戶報表查看
}
問題:
角色針對人劃分的,人做爲用戶在系統中屬於活動內容,若是該 角色能夠訪問的資源出現變動,須要修改你的代碼了,好比:須要變動爲部門經理和總經理均可以進行用戶報表查看,代碼改成:
if(user.hasRole('部門經理') || user.hasRole('總經理') ){
//系統資源內容
//用戶報表查看
}
基於角色的訪問控制是不利於系統維護(可擴展性不強)。
RBAC(Resource based access control),基於資源的訪問控制。
資源在系統中是不變的,好比資源有:類中的方法,頁面中的按鈕。
對資源的訪問須要具備permission權限,代碼能夠寫爲:
if(user.hasPermission ('用戶報表查看(權限標識符)')){
//系統資源內容
//用戶報表查看
}
上邊的方法就能夠解決用戶角色變動不用修改上邊權限控制的代碼。
若是須要變動權限只須要在分配權限模塊去操做,給部門經理或總經理增或刪除權限。
建議使用基於資源的訪問控制實現權限管理。