基本上涉及到使用者參與的系統都要進行許可權管理,許可權管理屬於系統安全的範疇,許可權管理實現對使用者訪問系統的控制,按照
安全規則或者
安全策略
控制使用者可以訪問而且只能訪問自己被授權的資源。
許可權管理包括使用者身份認證和授權兩部分,簡稱認證授權。對於需要訪問控制的資源使用者首先經過身份認證,認證通過後使用者具有該資源的訪問許可權方可訪問。
身份認證,就是判斷乙個使用者是否為合法使用者的處理過程。最常用的簡單身份認證方式是系統通過核對使用者輸入的使用者名稱和口令,看其是否與系統中儲存的該使用者的使用者名稱和口令一致,來判斷使用者身份是否正確。對於採用指紋等系統,則出示指紋;對於硬體key等刷卡系統,則需要刷卡。
上邊的流程圖中需要理解以下關鍵物件:
2.3.1subject:主體
訪問系統的使用者,主體可以是使用者、程式等,進行認證的都稱為主體;
2.3.2principal[ˈprɪnsəpl]:身份資訊
是主體(subject)進行身份認證的標識,標識必須具有唯一性,如使用者名稱、手機號、郵箱位址等,乙個主體可以有多個身份,但是必須有乙個主身份(primary principal)。
2.3.3credential[krəˈdenʃl]:憑證資訊
是只有主體自己知道的安全資訊,如密碼、證書等。
2.4.1概念
授權,即訪問控制,控制誰能訪問哪些資源。主體進行身份認證後需要分配許可權方可訪問系統的資源,對於某些資源沒有許可權是無法訪問的。
2.4.2授權流程
下圖中橙色為授權流程。
2.4.3關鍵物件
授權可簡單理解為who對what(which)進行how操作:
who,即主體(subject),主體需要訪問系統中的資源。
what,即資源(resource),如系統選單、頁面、按鈕、類方法、系統商品資訊等。資源包括資源型別和資源例項,比如商品資訊為資源型別,型別為t01的商品為資源例項,編號為001的商品資訊也屬於資源例項。
how,許可權/許可(permission)[pəˈmɪʃn],規定了主體對資源的操作許可,許可權離開資源沒有意義,如使用者查詢許可權、使用者新增許可權、某個類方法的呼叫許可權、編號為001使用者的修改許可權等,通過許可權可知主體對哪些資源都有哪些操作許可。許可權分為粗顆粒和細顆粒,粗顆粒許可權是指對資源型別的許可權,細顆粒許可權是對資源例項的許可權。
主體、資源、許可權關係如下圖:
使用者擁有了許可權即可操作許可權範圍內的資源,系統根據使用者所擁有的許可權進行訪問控制。
2.4.4.1基於角色的訪問控制
rbac基於角色的訪問控制(role-based access control)是以角色為中心進行訪問控制,比如:主體的角色為總經理可以查詢企業運營報表,查詢員工工資資訊等,訪問控制流程如下:
上圖中的判斷邏輯**可以理解為:
if(主體.hasrole("總經理角色id"))
缺點:以角色進行訪問控制粒度較粗,如果上圖中查詢工資所需要的角色變化為總經理和部門經理,此時就需要修改判斷邏輯為「判斷主體的角色是否是總經理或部門經理」,系統可擴充套件性差。
修改**如下:
if(主體.hasrole("總經理角色id") || 主體.hasrole("部門經理角色id"))
2.4.4.2基於資源的訪問控制rbac基於資源的訪問控制(resource-based access control)是以資源為中心進行訪問控制,比如:主體必須具有查詢工資許可權才可以查詢員工工資資訊等.
上圖中的判斷邏輯**可以理解為:
if(主體.haspermission("查詢工資許可權標識"))
優點:系統設計時定義好查詢工資的許可權標識,即使查詢工資所需要的角色變化為總經理和部門經理也只需要將「查詢工資資訊許可權」新增到「部門經理角色」的許可權列表中,判斷邏輯不用修改,系統可擴充套件性強。
對資源型別的管理稱為粗顆粒度許可權管理,即只控制到選單、按鈕、方法,粗粒度的例子比如:使用者具有使用者管理的許可權,具有匯出訂單明細的許可權。對資源例項的控制稱為細顆粒度許可權管理,即控制到資料級別的許可權,比如:使用者只允許修改本部門的員工資訊,使用者只允許匯出自己建立的訂單明細。
對於粗顆粒度的許可權管理可以很容易做系統架構級別的功能,即系統功能操作使用統一的粗顆粒度的許可權管理。
對於細顆粒度的許可權管理不建議做成系統架構級別的功能,因為對資料級別的控制是系統的業務需求,隨著業務需求的變更業務功能變化的可能性很大,建議對資料級別的許可權控制在業務層個性化開發,比如:使用者只允許修改自己建立的商品資訊可以在service介面新增校驗實現,service介面需要傳入當前操作人的標識,與商品資訊建立人標識對比,不一致則不允許修改商品資訊。
基於url攔截是企業中常用的許可權管理方法,實現思路是:將系統操作的每個url配置在許可權表中,將許可權對應到角色,將角色分配給使用者,使用者訪問系統功能通過filter進行過慮,過慮器獲取到使用者訪問的url,只要訪問的url是使用者分配角色中的url則放行繼續訪問。
如下圖:
對於許可權管理基本上每個系統都有,使用許可權管理框架完成許可權管理功能的開發可以節省系統開發時間,並且許可權管理框架提供了完善的認證和授權功能有利於系統擴充套件維護,但是學習許可權管理框架是需要成本的,所以選擇一款簡單高效的許可權管理框架顯得非常重要
一 shiro學習 許可權理論介紹
許可權管理 使用者認證 授權管理 按照一定的安全規則與策略控制使用者可以訪問而且只能訪問自己被授權的部分資源。使用者認證 判斷使用者是否屬於合法使用者的過程 人像核查 指紋核查 刷卡核查 使用者口令等等 使用者認證流程 關鍵物件 suject 主體 使用者 程式 principal身份資訊 身份認證...
shiro之許可權分配
編寫html 登入後的鏈結 th href 需要有admin角色的功能a th href 需要有admin角色的功能test01a th href 需要有admin角色的功能adda th href 需要有user角色的功能a 編寫controller nopermission public str...
許可權管理以及shiro的簡述(個人理解)
許可權管理簡要設計 資料庫表 許可權表 存貯各種許可權 url 使用者表 屬於某個組 組 角色 組中根據需求擁有各種許可權 角色表與組表性質類似 表關係 組和許可權表 多對多 組和使用者表 多對多 這裡的關係要根據實際需求來做決定,不是固定的 許可權表可以通過其他方式進行表示,這裡寫許可權表是為了方...