restful api 權限設計 - 初探一

restful api 權限設計 - 初探一

在如今主流的先後端分離的系統中，或者是專一於提供api服務的系統，如何保護好所提供的後端restful api，使得很是重要。保護api的方面不少，限流，防刷，校驗能夠說都是保護，今天來談談很重要的api的認證鑑權保護，大概的思路。需求兩點:首先認證 -- 咱們能夠配置哪些api須要用戶認證經過才能訪問哪些能夠直接訪問，還有就是鑑權 -- 咱們能夠配置管理哪些api對於某個用戶能調用哪些不能調用。

題外-有些會說頁面按鈕或者頁面顯示的權限問題，我的認爲按鈕，頁面這類的顯示不顯示，是前端的權限管理責任劃分，因此此次並不會去討論它。

認證

主流的認證方式有 token - jwt, basic auth, digest auth等，用戶攜帶認證信息訪問restful api，後端會有個前置過濾攔截器(filter,interceptor,aop均可以實現)來攔截請求，獲取請求信息裏的認證信息，經過算法校驗或者和系統內用戶數據源(能夠來自數據庫，文本等)對比判斷，校驗經過纔會讓用戶請求流程繼續下去。

這是個大概的認證流程，還有不少細節須要考慮到，好比有些api不須要認證也要被訪問，數據源的設計是怎麼樣的，用戶攜帶多種認證信息怎麼判斷等。

鑑權

用戶認證流程經過後，就須要對認證後的用戶訪問此api進行鑑權，判斷此用戶是否能訪問此api。主流易用的權限模型是RBAC - 基於角色的權限模型。咱們這裏對restful api來講就是， api賦權給角色，用戶擁有此角色，用戶就能訪問此restful api。即 用戶-角色-資源。

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

上面這個流程大概能夠抽象出這樣的配置數據：

對restful api來講，就是 /api/v2/host===post===[role2,role3,role4] 即對 /api/v2/host進行post請求的這個rest api，其賦權給角色role2,role3,role4。

對用戶來講，就是 - appId: root, credential: 23456, role: [role1,role2] 即用戶root密碼憑據是23456，擁有角色role1,role2。

當用戶admin認證經過後， post方式請求接口/api/v2/host時，因爲其擁有角色role2，而role2被賦權了/api/v2/host===post此資源，因此用戶能夠訪問此api。

抽象數據ok，這些數據從哪裏來也是問題。咱們能夠把它抽象爲數據源，通常的數據源咱們能夠是數據庫-5表結構便可，用戶表-角色表-資源表和兩個關係關聯表。若是沒有數據庫的系統，能夠是配置文本或者代碼註解形式等。

權限動態修改

對於權限配置數據，咱們固然但願是能夠動態修改而不是寫死到代碼裏面。若是要作到動態修改，那使用spring aop相似的切面來認證鑑權就不合適了。數據源應該須要來自數據庫或者配置文本，當數據源經過接口改動後，權限配置信息在內存中的值也須要同步修改。

url路徑匹配

認證鑑權以前還有個重要的一點就是路徑匹配，即咱們須要知道用戶訪問的restful api和咱們從數據源獲取的配置數據裏面的api或者規則進行匹配，匹配成功的咱們才知道這個api被賦權給了誰，這個api是否免登陸等。固然你也可使用相似spring aop同樣的切面在方法調用前認證鑑權，這樣就免去了路徑匹配，可是這樣的話就須要咱們寫死代碼，作不到動態修改權限信息。api url路徑匹配主流的就是ant匹配，看spring security 或者apache shiro都是用ant匹配規則，用請求的url和配置的鏈一個一個ant匹配。這其中是否還有更高效的方式呢。

---

上面就是對restful api 權限設計的粗略討論，以後的文章會討論下具體的實現細節，配置數據源爲數據庫時的表設計，jwt等各個認證方式實現，token刷新，路徑過濾鏈匹配更優化解等。

額外

介紹一款簡單高效面向restful api的jvm認證鑑權框架，shiro,spring security以外的第3個選擇。

sureness 主頁 - https://su.usthe.com/ github - https://github.com/tomsun28/s...

基於 rbac 主要關注於對 restful api 的安全保護
無特定框架依賴(本質就是過濾器處攔截判斷,已有springboot,quarkus,javalin,ktor等demo)
支持動態修改權限配置(動態修改哪些api須要被認證，能夠被誰訪問)
支持主流http容器 servlet 和 jax-rs
支持多種認證策略, jwt, basic auth, digest auth ... 可擴展自定義支持的認證方式 基於改進的字典匹配樹擁有的高性能 良好的擴展接口, demo和文檔