1 許可權管理

1.1 什麼是許可權管理

基本上涉及到使用者參與的系統都要進行許可權管理，許可權管理屬於系統安全的範疇，許可權管理實現對使用者訪問系統的控制，按照安全規則或者安全策略控制使用者可以訪問而且只能訪問自己被授權的資源。

許可權管理包括使用者身份認證和授權兩部分，簡稱認證授權。對於需要訪問控制的資源使用者首先經過身份認證，認證通過後使用者具有該資源的訪問許可權方可訪問。

1.2 使用者身份認證

1.2.1 概念

身份認證，就是判斷一個使用者是否為合法使用者的處理過程。最常用的簡單身份認證方式是系統通過核對使用者輸入的使用者名稱和口令，看其是否與系統中儲存的該使用者的使用者名稱和口令一致，來判斷使用者身份是否正確。對於採用

指紋等系統，則出示指紋；對於硬體Key等刷卡系統，則需要刷卡。

1.2.2 使用者名稱密碼身份認證流程

1.2.3 關鍵物件

上邊的流程圖中需要理解以下關鍵物件：

n Subject：主體

訪問系統的使用者，主體可以是使用者、程式等，進行認證的都稱為主體；

是主體（subject）進行身份認證的標識，標識必須具有唯一性，如使用者名稱、手機號、郵箱地址等，一個主體可以有多個身份，但是必須有一個主身份（Primary Principal）。

是隻有主體自己知道的安全資訊，如密碼、證書等。

1.3 授權

1.3.1 概念

授權，即訪問控制，控制誰能訪問哪些資源。主體進行身份認證後需要分配許可權方可訪問系統的資源，對於某些資源沒有許可權是無法訪問的。

1.3.2 授權流程

下圖中橙色為授權流程。

1.3.3 關鍵物件

授權可簡單理解為who對what(which)進行How操作：

n Who，即主體（Subject），主體需要訪問系統中的資源。

n What，即資源（Resource），如系統選單、頁面、按鈕、類方法、系統商品資訊等。資源包括資源型別和資源例項，比如商品資訊為資源型別，型別為t01的商品為資源例項，編號為001的商品資訊也屬於資源例項。

n How，許可權/許可（Permission），規定了主體對資源的操作許可，許可權離開資源沒有意義，如使用者查詢許可權、使用者新增許可權、某個類方法的呼叫許可權、編號為001使用者的修改許可權等，通過許可權可知主體對哪些資源都有哪些操作許可。

許可權分為粗顆粒和細顆粒，粗顆粒許可權是指對資源型別的許可權，細顆粒許可權是對資源例項的許可權。

主體、資源、許可權關係如下圖：

對上節中的主體、資源、許可權通過資料模型表示。

主體（賬號、密碼）

資源（資源名稱、訪問地址）

許可權（許可權名稱、資源id）

角色（角色名稱）

角色和許可權關係（角色id、許可權id）

主體和角色關係（主體id、角色id）

如下圖：

通常企業開發中將資源和許可權表合併為一張許可權表，如下：

資源（資源名稱、訪問地址）

許可權（許可權名稱、資源id）

合併為：

許可權（許可權名稱、資源名稱、資源訪問地址）

上圖常被稱為許可權管理的通用模型，不過企業在開發中根據系統自身的特點還會對上圖進行修改，但是使用者、角色、許可權、使用者角色關係、角色許可權關係是需要去理解的。

1.3.5 許可權分配

對主體分配許可權，主體只允許在許可權範圍內對資源進行操作，比如：對u01使用者分配商品修改許可權，u01使用者只能對商品進行修改。

許可權分配的資料通常需要持久化，根據上邊的資料模型建立表並將使用者的許可權資訊儲存在資料庫中。

1.3.6 許可權控制

使用者擁有了許可權即可操作許可權範圍內的資源，系統不知道主體是否具有訪問許可權需要對使用者的訪問進行控制。

1.3.6.1 基於角色的訪問控制

RBAC基於角色的訪問控制（Role-BasedAccess Control）是以角色為中心進行訪問控制，比如：主體的角色為總經理可以查詢企業運營報表，查詢員工工資資訊等，訪問控制流程如下：

if(主體.hasRole("總經理角色id")){

查詢工資

}

缺點：以角色進行訪問控制粒度較粗，如果上圖中查詢工資所需要的角色變化為總經理和部門經理，此時就需要修改判斷邏輯為“判斷主體的角色是否是總經理或部門經理”，系統可擴充套件性差。

修改程式碼如下：

if(主體.hasRole("總經理角色id") || 主體.hasRole("部門經理角色id")){

查詢工資

}

1.3.6.2 基於資源的訪問控制

RBAC基於資源的訪問控制（Resource-BasedAccess Control）是以資源為中心進行訪問控制，比如：主體必須具有查詢工資許可權才可以查詢員工工資資訊等，訪問控制流程如下：

上圖中的判斷邏輯程式碼可以理解為：

if(主體.hasPermission("查詢工資許可權標識")){

查詢工資

}

優點：系統設計時定義好查詢工資的許可權標識，即使查詢工資所需要的角色變化為總經理和部門經理也只需要將“查詢工資資訊許可權”新增到“部門經理角色”的許可權列表中，判斷邏輯不用修改，系統可擴充套件性強。

2 許可權管理解決方案

2.1.1 什麼是粗顆粒度和細顆粒度

對資源型別的管理稱為粗顆粒度許可權管理，即只控制到選單、按鈕、方法，粗粒度的例子比如：使用者具有使用者管理的許可權，具有匯出訂單明細的許可權。對資源例項的控制稱為細顆粒度許可權管理，即控制到資料級別的許可權，比如：使用者只允許修改本部門的員工資訊，使用者只允許匯出自己建立的訂單明細。

2.1.2 如何實現粗顆粒度和細顆粒度

對於粗顆粒度的許可權管理可以很容易做系統架構級別的功能，即系統功能操作使用統一的粗顆粒度的許可權管理。

對於細顆粒度的許可權管理不建議做成系統架構級別的功能，因為對資料級別的控制是系統的業務需求，隨著業務需求的變更業務功能變化的可能性很大，建議對資料級別的許可權控制在業務層個性化開發，比如：使用者只允許修改自己建立的商品資訊可以在service介面新增校驗實現，service介面需要傳入當前操作人的標識，與商品資訊建立人標識對比，不一致則不允許修改商品資訊。

2.2 基於url攔截

基於url攔截是企業中常用的許可權管理方法，實現思路是：將系統操作的每個url配置在許可權表中，將許可權對應到角色，將角色分配給使用者，使用者訪問系統功能通過Filter進行過慮，過慮器獲取到使用者訪問的url，只要訪問的url是使用者分配角色中的url則放行繼續訪問。

如下圖：

2.3 使用許可權管理框架

對於許可權管理基本上每個系統都有，使用許可權管理框架完成許可權管理功能的開發可以節省系統開發時間，並且許可權管理框架提供了完善的認證和授權功能有利於系統擴充套件維護，但是學習許可權管理框架是需要成本的，所以選擇一款簡單高效的許可權管理框架顯得非常重要。

3 基於url攔截實現

3.1 環境準備

jdk：1.7.0_72

web容器：tomcat7

系統框架：springmvc3.2.0+mybatis3.2.7（詳細參考springmvc教案）

前臺UI：jquery easyUI1.2.2

3.2 資料庫

建立mysql5.1資料庫

建立使用者表、角色表、許可權表、角色許可權關係表、使用者角色關係表。

匯入指令碼，先匯入shiro_sql_talbe.sql再匯入shiro-sql_table_data.sql

3.3 activeUser使用者身份類

使用者登陸成功記錄activeUser資訊並將activeUser存入session。

publicclass ActiveUser implements java.io.Serializable {

private String userid;//使用者id

private String usercode;// 使用者賬號

private String username;// 使用者名稱稱

private List<SysPermission> menus;// 選單

private List<SysPermission> permissions;// 許可權

3.4 anonymousURL.properties

anonymousURL.properties公開訪問地址，無需身份認證即可訪問。

3.5 commonURL.properties

commonURL.properties公共訪問地址，身份認證通過無需分配許可權即可訪問。

3.6 使用者身份認證攔截器

使用springmvc攔截器對使用者身份認證進行攔截，如果使用者沒有登陸則跳轉到登陸頁面，本功能也可以使用filter實現。

publicclass LoginInterceptor implements HandlerInterceptor {

// 在進入controller方法之前執行

// 使用場景：比如身份認證校驗攔截，使用者許可權攔截，如果攔截不放行，controller方法不再執行

@Override

publicboolean preHandle(HttpServletRequest request,

HttpServletResponse response, Object handler) throws Exception {

// 校驗使用者訪問是否是公開資源地址(無需認證即可訪問)

List<String> open_urls = ResourcesUtil.gekeyList("anonymousURL");

// 使用者訪問的url

String url = request.getRequestURI();

for (String open_url : open_urls) {

if (url.indexOf(open_url) >= 0) {

// 如果訪問的是公開地址則放行

returntrue;

}

// 校驗使用者身份是否認證通過

HttpSession session = request.getSession();

ActiveUser activeUser = (ActiveUser) session.getAttribute("activeUser");

if (activeUser != null) {

// 使用者已經登陸認證，放行

returntrue;

}

// 跳轉到登陸頁面

request.getRequestDispatcher("/WEB-INF/jsp/login.jsp").forward(request,

response);

returnfalse;

}

3.7 使用者授權攔截器

使用springmvc攔截器對使用者訪問url進行攔截，如果使用者訪問的url沒有分配許可權則跳轉到無權操作提示頁面（refuse.jsp），本功能也可以使用filter實現。

publicclass PermissionInterceptor implements HandlerInterceptor {

// 在進入controller方法之前執行

// 使用場景：比如身份認證校驗攔截，使用者許可權攔截，如果攔截不放行，controller方法不再執行

// 進入action方法前要執行

@Override

publicboolean preHandle(HttpServletRequest request,

HttpServletResponse response, Object handler) throws Exception {

// TODO Auto-generatedmethod stub

// 使用者訪問地址：

String url = request.getRequestURI();

// 校驗使用者訪問是否是公開資源地址(無需認證即可訪問)

List<String> open_urls = ResourcesUtil.gekeyList("anonymousURL");

// 使用者訪問的url

for (String open_url : open_urls) {

if (url.indexOf(open_url) >= 0) {

// 如果訪問的是公開地址則放行

returntrue;

}

//從 session獲取使用者公共訪問地址（認證通過無需分配許可權即可訪問）

List<String> common_urls = ResourcesUtil.gekeyList("commonURL");

// 使用者訪問的url

for (String common_url : common_urls) {

if (url.indexOf(common_url) >= 0) {

// 如果訪問的是公共地址則放行

returntrue;

}

// 從session獲取使用者許可權資訊

HttpSession session = request.getSession();

ActiveUser activeUser = (ActiveUser) session.getAttribute("activeUser");

// 取出session中許可權url

// 獲取使用者操作許可權

List<SysPermission> permission_list =activeUser.getPermissions();

// 校驗使用者訪問地址是否在使用者許可權範圍內

for (SysPermission sysPermission : permission_list) {

String permission_url = sysPermission.getUrl();

if (url.contains(permission_url)) {

returntrue;

}

// 跳轉到頁面

request.getRequestDispatcher("/WEB-INF/jsp/refuse.jsp").forward(

request, response);

returnfalse;

}

3.8 使用者登陸

使用者輸入使用者賬號和密碼登陸，登陸成功將使用者的身份資訊（使用者賬號、密碼、許可權選單、許可權url等）記入activeUser類，並寫入session。

3.8.1 controller

//使用者登陸提交

@RequestMapping("/loginsubmit")

public String loginsubmit(HttpSession session,Stringusercode,String password,String randomcode) throws Exception{

//校驗驗證碼

//從session獲取正確的驗證碼

String validateCode = (String)session.getAttribute("validateCode");

if(!randomcode.equals(validateCode)){

//丟擲異常：驗證碼錯誤

thrownew CustomException("驗證碼錯誤！");

}

//使用者身份認證

ActiveUser activeUser = sysService.authenticat(usercode,password);

//記錄session

session.setAttribute("activeUser", activeUser);

return"redirect:first.action";

}

3.8.2 service介面

/**

* <p>

*Title: authenticat

* </p>

* <p>

*Description:使用者認證

* </p>

* @param usercode

* 使用者賬號

* @param password

* 使用者密碼

* @return ActiveUser 使用者身份資訊

* @throws Exception

public ActiveUser authenticat(String usercode, String password)

throws Exception;

// 根據賬號查詢使用者

public SysUser findSysuserByUsercode(String usercode) throws Exception;

// 根據使用者id獲取許可權

public List<SysPermission> findSysPermissionList(Stringuserid)

throws Exception;

// 根據使用者id獲取選單

public List<SysPermission> findMenuList(Stringuserid) throws Exception;

4 shiro介紹

4.1 什麼是shiro

Shiro是apache旗下一個開源框架，它將軟體系統的安全認證相關的功能抽取出來，實現使用者身份認證，許可權授權、加密、會話管理等功能，組成了一個通用的安全認證框架。

4.2 為什麼要學shiro

既然shiro將安全認證相關的功能抽取出來組成一個框架，使用shiro就可以非常快速的完成認證、授權等功能的開發，降低系統成本。

shiro使用廣泛，shiro可以執行在web應用，非web應用，叢集分散式應用中越來越多的使用者開始使用shiro。

java領域中springsecurity(原名Acegi)也是一個開源的許可權管理框架，但是spring security依賴spring執行，而shiro就相對獨立，最主要是因為shiro使用簡單、靈活，所以現在越來越多的使用者選擇shiro。

4.3 Shiro架構

4.3.1 Subject

Subject即主體，外部應用與subject進行互動，subject記錄了當前操作使用者，將使用者的概念理解為當前操作的主體，可能是一個通過瀏覽器請求的使用者，也可能是一個執行的程式。 Subject在shiro中是一個介面，介面中定義了很多認證授相關的方法，外部程式通過subject進行認證授，而subject是通過SecurityManager安全管理器進行認證授權

SecurityManager即安全管理器，對全部的subject進行安全管理，它是shiro的核心，負責對所有的subject進行安全管理。通過SecurityManager可以完成subject的認證、授權等，實質上SecurityManager是通過Authenticator進行認證，通過Authorizer進行授權，通過SessionManager進行會話管理等。

SecurityManager是一個介面，繼承了Authenticator,Authorizer, SessionManager這三個介面。

4.3.3 Authenticator

Authenticator即認證器，對使用者身份進行認證，Authenticator是一個介面，shiro提供ModularRealmAuthenticator實現類，通過ModularRealmAuthenticator基本上可以滿足大多數需求，也可以自定義認證器。

4.3.4 Authorizer

Authorizer即授權器，使用者通過認證器認證通過，在訪問功能時需要通過授權器判斷使用者是否有此功能的操作許可權。

4.3.5 realm

Realm即領域，相當於datasource資料來源，securityManager進行安全認證需要通過Realm獲取使用者許可權資料，比如：如果使用者身份資料在資料庫那麼realm就需要從資料庫獲取使用者身份資訊。

注意：不要把realm理解成只是從資料來源取資料，在realm中還有認證授權校驗的相關的程式碼。

4.3.6 sessionManager

sessionManager即會話管理，shiro框架定義了一套會話管理，它不依賴web容器的session，所以shiro可以使用在非web應用上，也可以將分散式應用的會話集中在一點管理，此特性可使它實現單點登入。

4.3.7 SessionDAO

SessionDAO即會話dao，是對session會話操作的一套介面，比如要將session儲存到資料庫，可以通過jdbc將會話儲存到資料庫。

4.3.8 CacheManager

CacheManager即快取管理，將使用者許可權資料儲存在快取，這樣可以提高效能。

4.3.9 Cryptography

Cryptography即密碼管理，shiro提供了一套加密/解密的元件，方便開發。比如提供常用的雜湊、加/解密等功能。

4.4 shiro的jar包

與其它java開源框架類似，將shiro的jar包加入專案就可以使用shiro提供的功能了。shiro-core是核心包必須選用，還提供了與web整合的shiro-web、與spring整合的shiro-spring、與任務排程quartz整合的shiro-quartz等，下邊是shiro各jar包的maven座標。