權限設計的雜談
這篇文章的定位，不是宣傳某個架構，僅僅之是梳理一下有關權限方面的一些想法和最近項目中的一些探索過程。 我們主要想解決一下問題。
1、什麼是權限，程式員了解的權限和客戶所了解的權限是不是一緻的。
2、權限的劃分原則，權限到底是根據什麼原則進行組合的。
3、角色是使用者與權限之間的必要的關系嗎？角色到底承接了什麼作用。
4、如何進行合理的表設計。
5、安全架構。
1.什麼是權限
在很多與開發者也好，與客戶也好，溝通的過程中我們很多次提到了權限，但是權限具體的含義每個人了解的含義都不明确，這樣很容易造成雙方資訊不對稱，有的人就隻是把權限了解成某個頁面的是否可通路，但是有的人卻了解成其他的東西。是以我們要徹底的定義一下權限是什麼。
權限到底是名詞屬性還是動詞屬性，還是名詞、動詞屬性均包含，這對于權限的含義很重要。如果是名詞屬性的話，那麼它應該是有具體的指代物；如果是動詞，則應該具有行為表示。
- 權限的名詞屬性：api接口、頁面、功能點。
- 權限的動詞屬性：可操作、不可操作。
那麼我們現在來看，其實權限是名詞、動詞屬性，它一定是表達了兩層含義。即控制的對象、操作。
1、例如：權限A表示頁面A的可通路。
2、例如：權限B表示頁面B可通路且頁面内的功能b不可使用
3、例如：權限C表示接口C不可調用。
4、例如：權限D表示頁面D可通路，且接口D可通路。
那麼進一步的說明，權限可以表示單個控制的對象的操作集合，也可以表示多個控制的對象的操作集合。而這兩者的取舍則是有設計人員決定的。
一句話總結權限的含義：what（若幹元素）進行how（若幹操作）
2.權限的劃分原則
我們了解了權限的具體含義之後，接下來就是用的問題，我們該如何去使用權限，如何将系統中的操作元素進行一個組合，這個我借鑒網上的一篇文章來解釋。劃分原則可以按照“最小特權原則”和“資料抽象原則”。
- 最小特權原則
1、我先舉一個反例，我把系統中所有的元素和操作都組合成一個權限。一個使用者擁有這個權限就相當擁有了系統所有的功能，實際上這肯定是不行的，使用者在一套系統中一定有他不允許操作的内容，哪怕是超級管理者也可能會有不能操作的元素，那麼最大化權限則是行不通，因為不符合常理。
2、據此，我們就把權限再進行一個拆分，按照業務子產品進行拆分，但是這實際上也是不行的。就比如系統中的财務子產品，假定子產品中含有報帳頁面和申報頁面，如果按照子產品進行拆分，那麼肯定有使用者同時包含了兩個互斥功能。
3、根據1和2，我們需要按照最小化進行權限劃分。但是這個也是值得商榷的，因為不同系統，最小的權限劃分對于提供的功能來說，劃分的角度也是不同的。
- 資料抽象原則
1、“最小特權劃分”從某個程度上來說決定了控制的對象 ，而資料抽象原則是是決定了操作。
2、資料抽象從字面的意思來看，其實很難了解到底是什麼意思。通常我們口頭上說最多的是CRUD增删查改，這實際上就是資料抽象的一種，我們可以了解成元素操作許可權的意思。
3、但是CRUD并不是資料抽象的全部，增删查改用于單實體，基本是沒問題的，但是在建構關系上，其實是不夠用的，例如任免某個經理管轄某個部門，從業務表面而言它修改了經理的管轄範圍。但是從代碼底層建構上來說，它屬于在經理和部門間新增了一道關系，是以根據需求我們需要再額外的增加一類許可權“任免許可”，這一類型的擴充則需要根據系統實際的業務情況進行劃分。
“最小特權”和“資料抽象”分别決定了權限中控制的對象和操作，但是這裡面還差了一個角度，則是現階段非常普遍的前後端分離的權限劃分的問題。
- 服務端的權限
1、前後端分離下的服務端，本質而言隻是提供接口的或者rpc服務等其他資源服務的服務提供方。
2、服務端能提供的權限的鑒權機制的對象：接口服務（api或者其他形式的服務）不包含前端的頁面或頁面中的功能點。
3、前端或移動端的頁面元素的控制和鑒權實質上不由服務端控制。
4、服務端可以單獨的控制服務的權限。
5服務端的服務對象是前端、移動端、第三方用戶端，提供的服務是接口服務。
在前後端已經分離的情況下，服務端對于前端而言隻是接口的提供者，但無權幹涉前端頁面的展示，服務端對于前端而言，能提供的是僅鑒權服務的接口而已，但是頁面的構成，頁面的欄目菜單或頁面内的功能點的構成均由前端單獨完成的。
- 前端或移動端的權限
1、前端的鑒權包含頁面的可通路，和頁面上的某項功能按鈕是否可以操作。
2、前端和移動端的服務對象是使用者，提供的服務是可視化的頁面。
前後端的服務對象的責任劃厘清晰之後，我們就不會混雜權限的歸屬的問題，在過去前後端沒分離的情況下，頁面本身就是服務端的一體，就沒有這方面的問題。雖然厘清楚了各端本質提供的服務的情況，但是前後端分離的權限劃分中仍有新的問題。
1、因為服務端和前端的鑒權對象不一緻，服務端隻能鑒權到api接口，那麼是否将api接口和前端的頁面乃至頁面功能點進行資料庫表與表層面的綁定關系。
2、如果進行了進行了表與表之間的綁定關系，那麼整個權限系統的維護量，是否能在能承受範圍之内。
3、如果不進行表與表之間的綁定關系，前端頁面在操作功能的時候，服務端如何鑒權頁面調用的api接口是否在使用者可操作的權限之内？
其實上面的問題則需要一個取舍，要麼增加運維成本嚴格控制前端調用api接口的關系，偏重服務端的接口服務鑒權。要麼是給api接口和前端頁面及功能點再提供一個通性的邏輯判斷處理，如：頁面及調用的功能點屬于某個業務子產品的操作許可，而頁面觸發的接口也剛好是這個業務子產品的操作許可，那麼鑒權通過，否則鑒權失敗。這種就是屬于側重前端對于使用者的控制，弱化了接口級的控制。
3.角色與權限的關系
通過1，2的描述，基本确定了權限的定義和劃分一個權限的通用法則。使用者在系統中最終是通過權限來使用各種功能點，是否有必要在使用者和權限中間再額外的附加一個關系。在我們現在的權限設計中，是增加了這樣一層關系的，就是角色。
1、減少操作層面的重複性。角色其實就是一組權限的集合，是權限集合的更進階抽象，為了便于運維和實際管理，通過角色的賦予，替代了權限賦予使用者的繁瑣性，在一套系統中，普遍情況都是權限的數量多于角色的數量。
2、權限是控制對象和操作集合，它本身不存在任何狀态，但是在賦予在使用者身上則擁有了狀态，比如權限A中允許使用者通路頁面A，權限B允許使用者通路頁面B，權限D運作使用者通路B頁面，但是不允許通路A頁面。那麼這層關系的維護在角色層面的話，會更加清晰，也就是說本身角色具有權限集合組裝的政策問題，對于互斥的權限有不同的方案處理。（權限中沒有某個操作和權限中禁止某個操作，是兩個不同的角度，不能混為一談）
3、因為權限的可能存在互斥性，在實際業務中也會引發角色的互斥性，舉一個現實中的案例來解釋互斥性：張三是軟體部的負責人但因為工作的特殊性也同樣隸屬于業務部的普通員工，我們設定負責人是可以要求人事部門給本部門進行招聘的，在實際的情況中，張三能給軟體部招聘新員工，但是不能給業務部招聘員工。我們把這個案例運用在系統中，張三則是擁有負責人和普通員工兩個角色，但是招聘的功能如果不加以控制，則會發生張三給業務部招人的結果。于是為了解決角色的這類問題，引入了職責劃分的方案。
4、職責劃分分為：靜态、動态。所謂靜态職責劃分則是在角色建立之初就已經确定了角色的職責内容。動态職責劃分是系統運作過程中對使用者已有的角色進行控制，例如：某些角色不能共存在使用者身上（互斥）、角色或角色的配置設定數量限定（控制用量）、角色與角色同時隻能激活一個進行使用（時刻唯一）。
引入角色的概念後，實際上這已經是一個比較完整的RBAC的權限設計的模型了。
4.資料表的設計思路
根據3的結論，實質上已經有了一個基礎的表設計的雛形。在這裡就有一些值得注意的點。
- （1）問：權限表是否有必要存在？
- （1）答：這個要結合系統的實際使用場景進行考慮，如果系統中的權限的對象很單一，比如隻有頁面，或者隻有api接口的話，其實權限表可有可無。增權重限表反而會導緻初始化項目權限的工作量增加。但是若系統中的權限對象是多個，那麼權限表的存在就有了更深層次的意義。在權限對象是多個的情況，權限表的存在就是為了更好更抽象的組合“最小特權”及“責任劃分”的操作對象。同時，一旦系統中的操作對象增加了，隻需要給權限表增加一個對象表和關系表就可以了。這樣易于擴充。
- （2）問：api接口和頁面實際上是沒有關系的，但是在鑒權活動是有關系的，頁面若和api沒有一點綁定聯系的話，服務端接口調用的時候則要麼攔截掉所有指定的接口（頁面和api接口沒綁定的話，則頁面的接口調用都不能成功），服務端接口完全不攔截接口，也會不安全，但是api接口和頁面功能在表結構層面的綁定會産生運維的大量工作成本，如何更好的設計。
- （2）答：在權限如何劃分中已經提過了這一點，在表結構中，我們可以增加一張業務子產品表和操作表（也可以在資料字典表中增加這兩類資料），我們可以在頁面和功能點鐘 綁定業務子產品和操作表關系，在api接口的代碼層面去綁定業務子產品和操作，在邏輯上綁定關系，解耦表結構之間的關系，那麼可以在一定程度上解決這一點，這樣做隻會出現一種問題，那就是使用者通路頁面的時候可調用的api接口會比實際可調用的接口數要多，但是前端權限管理會隐藏功能點，這樣就在可視化的程度上解決了這個問題。
5.安全架構
由于我們是基于RBAC的權限設計，現行java架構下最常見的就是shiro和Spring Security 。這兩個就是仁者見仁智者見智了，我兩者都實用過。僅建議使用shiro的話，可以更好的了解RBAC的設計思路，Spring Security 也是個不錯的架構，但是它涉及到的概念太多，并不利于初學者去了解最基本的權限設計。我在這隻在學習的角度上去比較這兩個架構，并沒有再其他領域去做比較，也不去比較。
文章來源:
https://my.oschina.net/cloudcross/blog/1920706閱讀參考：
https://www.roncoo.com/course/list.html?courseName=%E6%9D%83%E9%99%90