//==============================================================
//權限管理原理：【以上圖爲準】
//==============================================================
什麼是權限管理:
|---解決的問題是：允許什麼樣的用戶訪問，允許用戶訪問什麼樣的資源
|---只要有用戶參與的系統，都有權限管理
|---按照安全規則或者安全策略控制用戶
|---權限管理包括用戶的認證和授權
//==============================================================
用戶的認證概念
|---用戶去訪問系統，系統要驗證用戶身份的合法性。
|
|---驗證方式多種多樣：
| |---用戶名+密碼
| |---指紋打開機：特徵身份標識
| |---基於證書驗證方法
|
|---系統驗證用戶身份合法，用戶方可訪問系統資源
用戶認證的流程
|---匿名訪問：不用認證，即可訪問
|---認證不通過：繼續認證
關鍵對象：
|---subject:主體，可以理解爲訪問對象，都要去訪問系統的資源，系統需要對subject進行身份認證。
|---principal:身份信息：通常是唯一的，一個主體有多個身份信息，但是都有一個主身份信息（手機號、用戶名、郵箱、綁定QQ等）
|---credential:憑證：可以是密碼、證書、指紋。
|---總結：主體在進行身份認證時需要提供身份信息和憑證信息。
此文老貓原創，轉載請加本文連接：http://blog.csdn.net/nthack5730/article/details/50964605
更多有關老貓的文章：http://blog.csdn.net/nthack5730
//==============================================================
用戶授權
|---簡單理解爲訪問控制
|---在用戶通過驗證後，系統對用戶訪問的資源進行控制。用戶具有資源的訪問權限方可訪問。
授權流程：
|---沒有訪問權限：拒絕訪問
關鍵對象
|---授權的過程：who對what(which)進行how操作
|---who：主體即subject，subject在認證通過後系統進行訪問控制
|---what(Which)：資源(resource)：subject必須具備資源的訪問權限，方可訪問該資源。
| |---資源分爲資源類型和資源實例
| |
| |---資源類型：相當於Java類
| | |---系統的用戶信息。
| |
| |---資源實例：相當於new的java對象
| | |---商品id爲001的商品信息。
|
|---how：權限或許可(permission)，針對資源的權限或許可，subject必須具有permission纔可訪問資源，如何操作、訪問，就必須定義permission
| |---用戶添加
| |---用戶修改
| |---商品刪除
//==============================================================
分配權限
|---用戶需要分配相應的權限，纔可訪問相應的資源，權限是對於資源的操作許可。
|---通常給用戶分配資源權限，需要將全縣信息持久化：存儲在數據庫中。
|---把用戶信息、權限管理、用戶分配的權限信息寫到數據庫中
|---分配權限模塊
//==============================================================
權限模型
|---用戶
|---資源
|---權限
此文老貓原創，轉載請加本文連接：http://blog.csdn.net/nthack5730/article/details/50964605
更多有關老貓的文章：http://blog.csdn.net/nthack5730
//==============================================================
權限控制（授權核心）
|---基於角色的訪問控制：RBAC:R(role)B(base)A(access)C(control)
| |---如：系統的角色包括部門經理、總經理.....(角色：針對用戶來劃分)
| | |---系統代碼實現：
| //如果該用戶是部門經理則可以訪問if中的代碼
| if(userHasRole("部門經理")){
| //系統資源內容
| //用戶報表查看
| }
|
| |---問題：角色針對人劃分的，人作爲用戶在系統中屬於活動內容。如果該角色可以訪問的資源出現變化，這時候就需要修改代碼。
| |---如：需要變更爲部門經理和總經理都可以查看報表，代碼變更：
| if(userHasRole("部門經理") || userHasRole("總經理")){
| //系統資源內容
| //用戶報表查看
| }
|
| |---因此：基於角色的訪問控制是不利於系統維護的（可擴展性不強）
|
|
|---基於資源的訪問控制：RBAC(Resources Based access control)
| |---資源在系統中是不變的，比如資源有：類中的方法、頁面中的按鈕
|
| |---對資源的訪問需要具有permission全新啊，代碼可以寫爲：
| if(userHasPermission("用戶報表查看"【權限標識符】)){
| //系統資源內容
| //用戶報表查看
| }//這個人有資源查看的權限就可以查看報表
| |---上面的這種方式就可以解決用戶角色變更而不用改權限控制的代碼
|
| |---假設：部門經理需要查看報表，那麼就給部門經理增加權限，其他人需要的話也進行同樣的操作即可。代碼不用改。
| |---即：如果需要變更權限，只需要在分配權限模塊操作，給部門經理或總經理增加或刪除權限。
|
|---推薦使用基於資源的訪問控制
此文老貓原創，轉載請加本文連接：http://blog.csdn.net/nthack5730/article/details/50964605
更多有關老貓的文章：http://blog.csdn.net/nthack5730
//==============================================================
// 權限管理解決方案
//==============================================================
|---什麼是粗粒度和細粒度
| |---粗粒度：對資源類型的權限管理。
| |---細粒度：對資源實例的權限管理。數據級別的權限管理。
|
|---資源類型和資源實例
| |---資源類型：菜單、URL鏈接、用戶添加頁面、用戶信息、類方法
| |---資源實例：資源類型的具體化
| |---用戶id爲001的修改鏈接
| |---s1110班級的用戶信息
| |---行政部的員工
|
|---粗粒度權限管理比如：超級管理員可以訪問用戶添加頁面、用戶信息等頁面
部門管理員可以訪問用戶信息頁面，包括所有按鈕
|
|---細粒度權限管理比如：部門經理只可以訪問本部門員工信息，用戶只可以看到自己的菜單
大區經理只能查看本轄區的銷售訂單
//==============================================================
// 如何實現粗顆粒和細顆粒的權限管理
//==============================================================
|---粗顆粒
| |---粗顆粒權限管理比較容易將權限管理代碼抽取出來在系統架構級別統一處理。
| 如：spring mvc的攔截器實現授權
|
|---細粒度
| |---對細粒度的權限管理在數據級別是沒有共性的。
| 針對細粒度權限管理就是系統業務邏輯的一部分。
| 如果在業務層去處理就相對比較簡單。
| 如果將細粒度權限管理統一在系統架構去抽取，比較困難、擴展性不強。
| |---針對細粒度權限管理在業務層控制
| |---如：部門經理只查看本部門的員工信息，在service接口提供一個部門id的參數，controller中根據當前用戶的
| 信息得到該用戶屬於哪個部門，調用service時將部門id傳入service，實現該用戶只查詢本部門員工。
|
//==============================================================
// 具體解決方案---使用Shiro【權限管理框架】
//==============================================================
|---對於粗粒度：建議使用優秀的權限管理框架實現
此文老貓原創，轉載請加本文連接：http://blog.csdn.net/nthack5730/article/details/50964605
更多有關老貓的文章：http://blog.csdn.net/nthack5730