1.1 什麼是權限管理
只要有用戶參與的系統一般都要有權限管理，權限管理實現對用戶訪問系統的控制，按照安全規則或者安全策略控制用戶可以訪問而且只能訪問自己被授權的資源。
權限管理包括用戶認證和授權兩部分。
1.2 用戶認證
1.2.1 概念
用戶認證，用戶去訪問系統，系統要驗證用戶身份的合法性。最常用的用戶身份驗證的方法：1、用戶名密碼方式、2、指紋打卡機、3、基於證書驗證方法。。系統驗證用戶身份合法，用戶方可訪問系統的資源。
1.2.2 用戶認證流程
1.2.3 關鍵對象
subject：主體，理解爲用戶,可能是程序，都要去訪問系統的資源，系統需要對subject進行身份認證。
principal：身份信息，通常是唯一的，一個主體還有多個身份信息，但是都有一個主身份信息（primary principal）
credential：憑證信息，可以是密碼 、證書、指紋。
總結：主體在進行身份認證時需要提供身份信息和憑證信息
1.3 用戶授權
1.3.1 概念
用戶授權，簡單理解爲訪問控制，在用戶認證通過後，系統對用戶訪問資源進行控制，用戶具有資源的訪問權限方可訪問。
1.3.2 授權流程
1.3.3 關鍵對象
授權的過程理解爲：who對what(which)進行how操作。
who：主體即subject，subject在認證通過後系統進行訪問控制。
what(which)：資源(Resource)，subject必須具備資源的訪問權限纔可訪問該 資源。資源比如：系統用戶列表頁面、商品修改菜單、商品id爲001的商品信息。
資源分爲資源類型和資源實例：
系統的用戶信息就是資源類型，相當於java類。
系統中id爲001的用戶就是資源實例，相當於new的java對象。
how：權限/許可(permission) ，針對資源的權限或許可，subject具有permission訪問資源，如何訪問/操作需要定義permission，權限比如：用戶添加、用戶修改、商品刪除。
1.3.4 權限模型
主體（賬號、密碼）
資源（資源名稱、訪問地址）
權限（權限名稱、資源id）
角色（角色名稱）
角色和權限關係（角色id、權限id）
主體和角色關係（主體id、角色id）
通常企業開發中將資源和權限表合併爲一張權限表，如下：
資源（資源名稱、訪問地址）
權限（權限名稱、資源id）
合併爲：
權限（權限名稱、資源名稱、資源訪問地址）
上圖常被稱爲權限管理的通用模型，不過企業在開發中根據系統自身的特點還會對上圖進行修改，但是用戶、角色、權限、用戶角色關係、角色權限關係是需要去理解的。
1.3.5 權限控制(授權核心)
1.3.5.1 基於角色的訪問控制
RBAC(role based access control)，基於角色的訪問控制。
比如：
系統角色包括 ：部門經理、總經理。。（角色針對用戶來劃分）
系統代碼中實現：
//如果該user是部門經理則可以訪問if中的代碼
if(user.hasRole('部門經理')){
//系統資源內容
//用戶報表查看
}
問題：
角色針對人劃分的，人作爲用戶在系統中屬於活動內容，如果該 角色可以訪問的資源出現變更，需要修改你的代碼了，比如：需要變更爲部門經理和總經理都可以進行用戶報表查看，代碼改爲：
if(user.hasRole('部門經理') || user.hasRole('總經理') ){
//系統資源內容
//用戶報表查看
}
基於角色的訪問控制是不利於系統維護(可擴展性不強)。
1.3.5.2 基於資源的訪問控制
RBAC(Resource based access control)，基於資源的訪問控制。
資源在系統中是不變的，比如資源有：類中的方法，頁面中的按鈕。
對資源的訪問需要具有permission權限，代碼可以寫爲：
if(user.hasPermission ('用戶報表查看（權限標識符）')){
//系統資源內容
//用戶報表查看
}
上邊的方法就可以解決用戶角色變更不用修改上邊權限控制的代碼。
如果需要變更權限只需要在分配權限模塊去操作，給部門經理或總經理增或刪除權限。
建議使用基於資源的訪問控制實現權限管理