sureness - 一個面向restful api保護的權限認證

sureness - 面向restful api的權限認證

倉庫地址

Background

目前 java主流的權限框架有 shiro，spring security
下面對於它們的探討都是我的淺薄之見，接受糾正
shiro對於 restful api原生支持不是太友好,須要改寫一些代碼,2年前一個項目就是改造 shiro,使其在過濾鏈就能匹配不一樣的 rest請求進行權限校驗,項目傳送門 booshiro,以後給 shiro commit幾回 pr, fix其在過濾鏈匹配時的危險漏洞, PR傳送門 SHIRO-682,總的來講 shiro很強大但其起源並不是面向 web,對 restful不是很友好
spring security很強大,與 spring深度集成,離開 spring,好比 google的精簡 guice,以前用過的 osgi框架 karaf就用不了了
它們都會在鏈式匹配這塊，用請求的url和配置的鏈一個一個 ant匹配(匹配過程當中會有緩存等提升性能)，但匹配的鏈過多時仍是比較耗性能
因此想寫一個權限包吸收上面的優秀設計,加一些本身的想法

Introduction

sureness 是做者在使用 java權限框架 shiro以後,吸收其良好的設計加上一些本身想法實現的全新認證鑑權項目
面對 restful api的認證鑑權,基於 RABC主要關注於對 restful api的保護
原生支持 restful api, websocket protection
原生支持動態權限(權限配置的動態加載)
原生支持 jwt, Basic Auth ... 可擴展自定義支持的認證方式
基於改進的字典匹配樹大大提升性能

sureness的低配置，易擴展，不耦合其餘框架，能使開發者對本身的項目多場景快速安全的進行保護

倉庫的組成部分:

• sureness的核心代碼--sureness-core
• 使用sureness10分鐘搭建權限項目--sample-bootstrap
• 使用sureness30分鐘搭建權限項目--sample-tom

一些約定

• 基於RABC,但只有(角色-資源)的映射,沒有(權限)動做
• 咱們將restful api請求視做一個資源,資源格式爲: requestUri===httpMethod
  即請求的路徑加上其請求方式(post,get,put,delete...)做爲一個總體被視做一個資源
  eg: /api/v2/book===get get方式請求/api/v2/book接口數據
• 用戶所屬角色--角色擁有資源--用戶擁有資源(用戶就能訪問此api)

使用

maven座標

<!-- https://mvnrepository.com/artifact/com.usthe.sureness/sureness-core -->
<dependency>
    <groupId>com.usthe.sureness</groupId>
    <artifactId>sureness-core</artifactId>
    <version>0.0.2.3</version>
</dependency>

gradle座標

compile group: 'com.usthe.sureness', name: 'sureness-core', version: '0.0.2.3'

入口,通常放在攔截全部請求的filter:

SurenessSecurityManager.getInstance().checkIn(servletRequest)

認證鑑權成功直接經過,失敗拋出特定異常,捕獲異常:

try {
            SubjectSum subject = SurenessSecurityManager.getInstance().checkIn(servletRequest);
        } catch (ProcessorNotFoundException | UnknownAccountException | UnsupportedSubjectException e4) {
            // 帳戶建立相關異常 
        } catch (DisabledAccountException | ExcessiveAttemptsException e2 ) {
            // 帳戶禁用相關異常
        } catch (IncorrectCredentialsException | ExpiredCredentialsException e3) {
            // 認證失敗相關異常
        } catch (UnauthorizedException e5) {
            // 鑑權失敗相關異常
        } catch (RuntimeException e) {
            // 其餘自定義異常
        }

sureness異常	異常描述
SurenessAuthenticationException	基礎認證異常,認證相關的子異常應該繼承此異常
SurenessAuthorizationException	基礎鑑權異常,鑑權相關的子異常應該繼承此異常
ProcessorNotFoundException	認證異常,未找到支持此subject的processor
UnknownAccountException	認證異常,不存在此帳戶
UnSupportedSubjectException	認證異常,不支持的請求,未建立出subject
DisabledAccountException	認證異常,帳戶禁用
ExcessiveAttemptsException	認證異常,帳戶嘗試認證次數過多
IncorrectCredentialsException	認證異常,密鑰錯誤
ExpiredCredentialsException	認證異常,密鑰認證過時
UnauthorizedException	鑑權異常,沒有權限訪問此資源

自定義異常須要繼承SurenessAuthenticationException或SurenessAuthorizationException才能被最外層捕獲

若權限配置數據來自文本,請參考使用sureness10分鐘搭建權限項目--sample-bootstrap

若權限配置數據來自數據庫,請參考使用sureness30分鐘搭建權限項目--sample-tom

HAVE FUN

進階擴展

若是瞭解 處理流程,就大概知道sureness提供的擴展點
sureness支持自定義subject，自定義subjectCreator註冊，自定義processor處理器等

擴展以前須要瞭解如下接口:

• Subject: 認證鑑權對象接口,提供訪問對象的帳戶密鑰,請求資源,角色等信息
• SubjectCreate: 建立Subject接口,根據請求內容建立不一樣類型的Subject對象
• Processor: Subject處理接口,根據Subject信息,進行認證鑑權
• PathTreeProvider: 資源的數據源接口,實現從數據庫,文本等加載數據
• SurenessAccountProvider: 用戶的帳戶密鑰信息接口,實現從數據庫,文本等加載數據

sureness大體流程:

graph TD
A(用戶請求體進來) --> B(s)
B(subjectCreate根據請求頭內容建立不一樣的鑰匙subject,每把鑰匙均可以嘗試) --> C(s)
C(不一樣的鑰匙認證方式即不一樣的鎖processor來處理進來的鑰匙subject) --> D(s)
D(以上一次成功即成功並結束,失敗即下一個鑰匙鎖嘗試直到全部嘗試結束)

1. 自定義數據源

實現 PathTreeProvider的接口, 加載到DefaultPathRoleMatcher中
實現 SurenessAccountProvider的接口,加載到須要的processor中

1. 自定義subject

實現Subject接口,添加自定義的subject內容
實現SubjectCreate接口方法,建立出自定義的subject
實現Processor接口,支持處理自定義的subject

1. 自定義processor

一個subject固然也能夠被不一樣的processor處理,因此能夠單獨自定義processor
實現Processor接口,設置支持的subject,實現處理該subject的邏輯

具體擴展實踐請參考 使用sureness30分鐘搭建權限項目--sample-tom

高性能匹配

處理流程

轉載請註明 from tomsun28