RBAC
基于角色的權限訪問控制（Role-Based Access Control）。
RBAC支持三個著名的安全原則：最小權限原則，責任分離原則和數據抽象原則。
RBAC認為權限授權實際上是Who、What、How的問題。在RBAC模型中，who、what、how構成了訪問權限三元組,也就是“Who對What(Which)進行How的操作”。
Who：權限的擁用者或主體（如Principal、User、Group、Role、Actor等等）。
What：權限針對的對象或資源（Resource、Class）。
How：具體的權限（Privilege,正向授權與負向授權）。
Shiro
Apache Shiro是一個強大且易用的Java安全框架,執行身份驗證、授權、密碼學和會話管理。
其基本功能點如下圖所示：
Authentication：身份認證 / 登錄，驗證用戶是不是擁有相應的身份；
Authorization：授權，即權限驗證，驗證某個已認證的用戶是否擁有某個權限；即判斷用戶是否能做事情，常見的如：驗證某個用戶是否擁有某個角色。或者細粒度的驗證某個用戶對某個資源是否具有某個權限；
Session Manager：會話管理，即用戶登錄后就是一次會話，在沒有退出之前，它的所有信息都在會話中；會話可以是普通 JavaSE 環境的，也可以是如 Web 環境的；
Cryptography：加密，保護數據的安全性，如密碼加密存儲到數據庫，而不是明文存儲；
Web Support：Web 支持，可以非常容易的集成到 Web 環境；
Caching：緩存，比如用戶登錄后，其用戶信息、擁有的角色 / 權限不必每次去查，這樣可以提高效率；
Concurrency：shiro 支持多線程應用的并發驗證，即如在一個線程中開啟另一個線程，能把權限自動傳播過去；
Testing：提供測試支持；
Run As：允許一個用戶假裝為另一個用戶（如果他們允許）的身份進行訪問；
Remember Me：記住我，這個是非常常見的功能，即一次登錄后，下次再來的話不用登錄了。
Shiro 不會去維護用戶、維護權限；這些需要我們自己去設計 / 提供；然后通過相應的接口注入給 Shiro 。
從應用程序角度觀察如何使用Shiro完成工作
Subject：主體，代表了當前 “用戶”，這個用戶不一定是一個具體的人，與當前應用交互的任何東西都是 Subject，如網絡爬蟲，機器人等；即一個抽象概念；所有 Subject 都綁定到 SecurityManager，與 Subject 的所有交互都會委托給 SecurityManager；可以把 Subject 認為是一個門面；SecurityManager 才是實際的執行者；
SecurityManager：安全管理器；即所有與安全有關的操作都會與 SecurityManager 交互；且它管理著所有 Subject；可以看出它是 Shiro 的核心，它負責與后邊介紹的其他組件進行交互，如果學習過 SpringMVC，你可以把它看成 DispatcherServlet 前端控制器；
Realm：域，Shiro 從從 Realm 獲取安全數據（如用戶、角色、權限），就是說 SecurityManager 要驗證用戶身份，那么它需要從 Realm 獲取相應的用戶進行比較以確定用戶身份是否合法；也需要從 Realm 得到用戶相應的角色 / 權限進行驗證用戶是否能進行操作；可以把 Realm 看成 DataSource，即安全數據源。
從 Shiro 內部來看Shiro 的架構
Subject：主體，可以看到主體可以是任何可以與應用交互的 “用戶”；
SecurityManager：相當于 SpringMVC 中的 DispatcherServlet 或者 Struts2 中的 FilterDispatcher；是 Shiro 的心臟；所有具體的交互都通過 SecurityManager 進行控制；它管理著所有 Subject、且負責進行認證和授權、及會話、緩存的管理。
Authenticator：認證器，負責主體認證的，這是一個擴展點，如果用戶覺得 Shiro 默認的不好，可以自定義實現；其需要認證策略（Authentication Strategy），即什么情況下算用戶認證通過了；
Authrizer：授權器，或者訪問控制器，用來決定主體是否有權限進行相應的操作；即控制著用戶能訪問應用中的哪些功能；
Realm：可以有 1 個或多個 Realm，可以認為是安全實體數據源，即用于獲取安全實體的；可以是 JDBC 實現，也可以是 LDAP 實現，或者內存實現等等；由用戶提供；注意：Shiro 不知道你的用戶 / 權限存儲在哪及以何種格式存儲；所以我們一般在應用中都需要實現自己的 Realm；
SessionManager：如果寫過 Servlet 就應該知道 Session 的概念，Session 呢需要有人去管理它的生命周期，這個組件就是 SessionManager；而 Shiro 并不僅僅可以用在 Web 環境，也可以用在如普通的 JavaSE 環境、EJB 等環境；所有呢，Shiro 就抽象了一個自己的 Session 來管理主體與應用之間交互的數據；這樣的話，比如我們在 Web 環境用，剛開始是一臺 Web 服務器；接著又上了臺 EJB 服務器；這時想把兩臺服務器的會話數據放到一個地方，這個時候就可以實現自己的分布式會話（如把數據放到 Memcached 服務器）；
SessionDAO：DAO 大家都用過，數據訪問對象，用于會話的 CRUD，比如我們想把 Session 保存到數據庫，那么可以實現自己的 SessionDAO，通過如 JDBC 寫到數據庫；比如想把 Session 放到 Memcached 中，可以實現自己的 Memcached SessionDAO；另外 SessionDAO 中可以使用 Cache 進行緩存，以提高性能；
CacheManager：緩存控制器，來管理如用戶、角色、權限等的緩存的；因為這些數據基本上很少去改變，放到緩存中后可以提高訪問的性能
Cryptography：密碼模塊，Shiro 提高了一些常見的加密組件用于如密碼加密 / 解密的。
使用Shiro做身份驗證
身份認證流程
-
首先調用 Subject.login(token) 進行登錄，其會自動委托給 Security Manager，調用之前必須通過 SecurityUtils.setSecurityManager() 設置；
-
SecurityManager 負責真正的身份驗證邏輯；它會委托給 Authenticator 進行身份驗證；
-
Authenticator 才是真正的身份驗證者，Shiro API 中核心的身份認證入口點，此處可以自定義插入自己的實現；
-
Authenticator 可能會委托給相應的 AuthenticationStrategy 進行多 Realm 身份驗證，默認 ModularRealmAuthenticator 會調用 AuthenticationStrategy 進行多 Realm 身份驗證；
-
Authenticator 會把相應的 token 傳入 Realm，從 Realm 獲取身份驗證信息，如果沒有返回 / 拋出異常表示身份驗證失敗了。此處可以配置多個 Realm，將按照相應的順序及策略進行訪問。
本文使用SqlLite+Druid做數據庫設計。
首先建立SqlLite數據庫shiro.db，并建立三張表。（推薦使用Navicat Premium客戶端操作SqlLite）
create table users (
id bigint auto_increment,
username varchar(100),
password varchar(100),
password_salt varchar(100),
constraint pk_users primary key(id)
);
create unique index idx_users_username on users(username);
create table user_roles(
id bigint auto_increment,
username varchar(100),
role_name varchar(100),
constraint pk_user_roles primary key(id)
);
create unique index idx_user_roles on user_roles(username, role_name);
create table roles_permissions(
id bigint auto_increment,
role_name varchar(100),
permission varchar(100),
constraint pk_roles_permissions primary key(id)
);
create unique index idx_roles_permissions on roles_permissions(role_name, permission);
編寫shiro配置文件
jdbcRealm=org.apache.shiro.realm.jdbc.JdbcRealm
dataSource=com.alibaba.druid.pool.DruidDataSource
dataSource.driverClassName=org.sqlite.JDBC
dataSource.url=jdbc:sqlite::resource:shiro.db
jdbcRealm.dataSource=$dataSource
jdbcRealm.permissionsLookupEnabled = true
securityManager.realms=$jdbcRealm
數據庫中增加記錄users("administrator", "123","null")，編寫測試代碼
//classpath:指定配置文件在src目錄下
Factory<org.apache.shiro.mgt.SecurityManager>factory=new IniSecurityManagerFactory("classpath:shiro.ini");
org.apache.shiro.mgt.SecurityManager securityManager = factory.getInstance();
SecurityUtils.setSecurityManager(securityManager);
Subject subject = SecurityUtils.getSubject();
UsernamePasswordToken token = new UsernamePasswordToken("administrator", "123");
try {
subject.login(token);
} catch (AuthenticationException e) {
e.printStackTrace();
}
if(subject.isAuthenticated()){
System.out.println("身份驗證成功！");
}
subject.logout();
ThreadContext.unbindSubject();
使用Shiro做授權管理
授權，也叫訪問控制，即在應用中控制誰能訪問哪些資源（如訪問頁面/編輯數據/頁面操作等）。在授權中需了解的幾個關鍵對象：主體（Subject）、資源（Resource）、權限（Permission）、角色（Role）。
主體
主體，即訪問應用的用戶，在 Shiro 中使用 Subject 代表該用戶。用戶只有授權后才允許訪問相應的資源。
資源
在應用中用戶可以訪問的任何東西，比如訪問 JSP 頁面、查看/編輯某些數據、訪問某個業務方法、打印文本等等都是資源。用戶只要授權后才能訪問。
權限
安全策略中的原子授權單位，通過權限我們可以表示在應用中用戶有沒有操作某個資源的權力。即權限表示在應用中用戶能不能訪問某個資源，如： 訪問用戶列表頁面；查看/新增/修改/刪除用戶數據（即很多時候都是 CRUD（增查改刪）式權限控制）。
如上可以看出，權限代表了用戶有沒有操作某個資源的權利，即反映在某個資源上的操作允不允許，不反映誰去執行這個操作。所以后續還需要把權限賦予給用戶，即定義哪個用戶允許在某個資源上做什么操作（權限），Shiro 不會去做這件事情，而是由實現人員提供。
Shiro 支持粗粒度權限（如用戶模塊的所有權限）和細粒度權限（操作某個用戶的權限，即實例級別的）。
角色
角色代表了操作集合，可以理解為權限的集合，一般情況下我們會賦予用戶角色而不是權限，即這樣用戶可以擁有一組權限，賦予權限時比較方便。典型的如：項目經理、技術總監、CTO、開發工程師等都是角色，不同的角色擁有一組不同的權限。
隱式角色：
即直接通過角色來驗證用戶有沒有操作權限，如在應用中 CTO、技術總監、開發工程師可以使用打印機，假設某天不允許開發工程師使用打印機，此時需要從應用中刪除相應代碼；再如在應用中 CTO、技術總監可以查看用戶、查看權限；突然有一天不允許技術總監查看用戶、查看權限了，需要在相關代碼中把技術總監角色從判斷邏輯中刪除掉；即粒度是以角色為單位進行訪問控制的，粒度較粗；如果進行修改可能造成多處代碼修改。
顯示角色：
在程序中通過權限控制誰能訪問某個資源，角色聚合一組權限集合；這樣假設哪個角色不能訪問某個資源，只需要從角色代表的權限集合中移除即可；無須修改多處代碼；即粒度是以資源/實例為單位的；粒度較細。
授權流程
-
首先調用 Subject.isPermitted*/hasRole*接口，其會委托給 SecurityManager，而 SecurityManager 接著會委托給 Authorizer；
-
Authorizer 是真正的授權者，如果我們調用如 isPermitted(“user:view”)，其首先會通過 PermissionResolver 把字符串轉換成相應的 Permission 實例；
-
在進行授權之前，其會調用相應的 Realm 獲取 Subject 相應的角色/權限用于匹配傳入的角色/權限；
-
Authorizer 會判斷 Realm 的角色/權限是否和傳入的匹配，如果有多個 Realm，會委托給 ModularRealmAuthorizer 進行循環判斷，如果匹配如 isPermitted*/hasRole* 會返回 true，否則返回 false 表示授權失敗。
基于角色的訪問控制（隱式角色）
數據庫中增加記錄user_roles("administrator", "role1")，編寫測試代碼
if(subject.hasRole("role1")) {
System.out.println("角色權限驗證成功！");
}
基于資源的訪問控制（顯示角色）
數據庫中增加記錄roles_permissions("role1", "*:view")，編寫測試代碼
if(subject.isPermitted("test1:view")) {
System.out.println("資源權限驗證成功！");
}
字符串通配符權限
規則：“資源標識符：操作：對象實例 ID” 即對哪個資源的哪個實例可以進行什么操作。其默認支持通配符權限字符串，“:”表示資源/操作/實例的分割；“,”表示操作的分割；“*”表示任意資源/操作/實例。
-
單個資源單個權限
system:user:update
-
單個資源多個權限
system:user:update,system:user:delete
-
單個資源全部權限
system:user:*
-
所有資源某個權限
*:view
用戶擁有所有資源的“view”所有權限。
-
單個實例單個權限
user:view:1
對資源 user 的 1 實例擁有 view 權限。
-
單個實例所有權限
user:*:1
-
所有實例單個權限
auth:*
-
所有實例所有權限
user:*:*
-
Shiro 對權限字符串缺失部分的處理
如“user:view”等價于“user:view:*”；而“organization”等價于“organization:*”或者“organization:*:*”。可以這么理解，這種方式實現了前綴匹配。
另外如“user:*”可以匹配如“user:delete”、“user:delete”可以匹配如“user:delete:1”、“user:*:1”可以匹配如“user:view:1”、“user”可以匹配“user:view”或“user:view:1”等。即*可以匹配所有，不加*可以進行前綴匹配；但是如“*:view”不能匹配“system:user:view”，需要使用“*:*:view”，即后綴匹配必須指定前綴（多個冒號就需要多個*來匹配）。
