什麼是權限管理
隻要有使用者參與的系統一般都要有權限管理，權限管理實作對使用者通路系統的控制，按照安全規則或者安全政策控制使用者可以通路而且隻能通路自己被授權的資源。
權限管理包括使用者認證和授權兩部分。
使用者認證
概念
使用者認證，使用者去通路系統，系統要驗證使用者身份的合法性。最常用的使用者身份驗證的方法：
1、使用者名密碼方式
2、指紋打卡機
3、基于證書驗證方法
系統驗證使用者身份合法，使用者方可通路系統的資源。
使用者認證流程
關鍵對象
subject：主體，了解為使用者,可能是程式，都要去通路系統的資源，系統需要對subject進行身份認證。
principal：身份資訊，通常是唯一的，一個主體還有多個身份資訊，但是都有一個主身份資訊（primary principal）
credential：憑證資訊，可以是密碼 、證書、指紋。
總結：主體在進行身份認證時需要提供身份資訊和憑證資訊。
使用者授權
使用者授權，簡單了解為通路控制，在使用者認證通過後，系統對使用者通路資源進行控制，使用者具有資源的通路權限方可通路。
授權流程
授權的過程了解為：who對what(which)進行how操作。
who：主體即subject，subject在認證通過後系統進行通路控制。
what(which)：資源(resource)，subject必須具備資源的通路權限才可通路該 資源。資源比如：系統使用者清單頁面、商品修改菜單、商品id為001的商品資訊。
資源分為資源類型和資源執行個體：
系統的使用者資訊就是資源類型，相當于java類。
系統中id為001的使用者就是資源執行個體，相當于new的java對象。
how：權限/許可(permission) ，針對資源的權限或許可，subject具有permission通路資源，如何通路/操作需要定義permission，權限比如：使用者添加、使用者修改、商品删除。
權限模型
主體（賬号、密碼）
資源（資源名稱、通路位址）
權限（權限名稱、資源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 (‘使用者報表檢視（權限辨別符）’)){
上邊的方法就可以解決使用者角色變更不用修改上邊權限控制的代碼。
如果需要變更權限隻需要在配置設定權限子產品去操作，給部門經理或總經理增或删除權限。
建議使用基于資源的通路控制實作權限管理。
基于角色的權限控制：根據角色判斷是否有操作權限，因為角色的變化性較高，如果角色修改需要修改控制代碼，系統可擴充性不強。
基于資源的權限控制：根據資源權限是否有操作權限，因為資源相對固定，如果角色修改或角色中權限修改不需要修改控制代碼，使用此方法系統可維護性很強。建議使用。
權限管了解決方案
什麼是粗粒度和細粒度權限
粗粒度權限管理，對資源類型的權限管理。資源類型比如：菜單、url連接配接、使用者添加頁面、使用者資訊、類方法、頁面中按鈕。。
粗粒度權限管理比如：超級管理者可以通路戶添加頁面、使用者資訊等全部頁面。
部門管理者可以通路使用者資訊頁面包括 頁面中所有按鈕。
細粒度權限管理，對資源執行個體的權限管理。資源執行個體就資源類型的具體化，比如：使用者id為001的修改連接配接，1110班的使用者資訊、行政部的員工。
細粒度權限管理就是資料級别的權限管理。
細粒度權限管理比如：部門經理隻可以通路本部門的員工資訊，使用者隻可以看到自己的菜單，大區經理隻能檢視本轄區的銷售訂單。。
粗粒度和細粒度例子：
系統有一個使用者清單查詢頁面，對使用者清單查詢分權限，如果粗顆粒管理，張三和李四都有使用者清單查詢的權限，張三和李四都可以通路使用者清單查詢。
進一步進行細顆粒管理，張三（行政部）和李四(開發部)隻可以查詢自己本部門的使用者資訊。張三隻能檢視行政部 的使用者資訊，李四隻能檢視開發部門的使用者資訊。細粒度權限管理就是資料級别的權限管理。
如何實作粗粒度和細粒度權限管理
如何實作粗粒度權限管理？
粗粒度權限管理比較容易将權限管理的代碼抽取出來在系統架構級别統一處理。比如：通過springmvc的攔截器實作授權。
如何實作細粒度權限管理？
對細粒度權限管理在資料級别是沒有共性可言，針對細粒度權限管理就是系統業務邏輯的一部分，如果在業務層去處理相對比較簡單，如果将細粒度權限管理統一在系統架構級别去抽取，比較困難，即使抽取的功能可能也存在擴充不強。
建議細粒度權限管理在業務層去控制。
比如：部門經理隻查詢本部門員工資訊，在service接口提供一個部門id的參數，controller中根據目前使用者的資訊得到該 使用者屬于哪個部門，調用service時将部門id傳入service，實作該使用者隻查詢本部門的員工。
基于url攔截的方式實作
基于url攔截的方式實作在實際開發中比較常用的一種方式。
對于web系統，通過filter過慮器實作url攔截，也可以springmvc的攔截器實作基于url的攔截。
使用權限管理架構實作
對于粗粒度權限管理，建議使用優秀權限管理架構來實作，節省開發成功，提高開發效率。
shiro就是一個優秀權限管理架構。
基于url的權限管理
基于url權限管理流程