權限設計的雜談
這篇文章的定位,不是宣傳某個框架,僅僅之是梳理一下有關權限方面的一些想法和最近項目中的一些探索過程。 我們主要想解決一下問題。
1.什麼是權限
在很多與開發者也好,與客戶也好,溝通的過程中我們很多次提到了權限,但是權限具體的含義每個人理解的含義都不明確,這樣很容易造成雙方信息不對稱,有的人就只是把權限理解成某個頁面的是否可訪問,但是有的人卻理解成其他的東西。所以我們要徹底的定義一下權限是什麼。
權限到底是名詞屬性還是動詞屬性,還是名詞、動詞屬性均包含,這對於權限的含義很重要。如果是名詞屬性的話,那麼它應該是有具體的指代物;如果是動詞,則應該具有行為表示。
權限的名詞屬性:api接口、頁面、功能點。權限的動詞屬性:可操作、不可操作。那麼我們現在來看,其實權限是名詞、動詞屬性,它一定是表達了兩層含義。即控制的對象、操作
那麼進一步的說明,權限可以表示單個控制的對象的操作集合,也可以表示多個控制的對象的操作集合。而這兩者的取捨則是有設計人員決定的。
一句話總結權限的含義:what(若干元素)進行how(若干操作)
2.權限的劃分原則
我們瞭解了權限的具體含義之後,接下來就是用的問題,我們該如何去使用權限,如何將系統中的操作元素進行一個組合,這個我借鑑網上的一篇文章來解釋。劃分原則可以按照“最小特權原則”和“數據抽象原則”。
最小特權原則我先舉一個反例,我把系統中所有的元素和操作都組合成一個權限。一個用戶擁有這個權限就相當擁有了系統所有的功能,實際上這肯定是不行的,用戶在一套系統中一定有他不允許操作的內容,哪怕是超級管理員也可能會有不能操作的元素,那麼最大化權限則是行不通,因為不符合常理。據此,我們就把權限再進行一個拆分,按照業務模塊進行拆分,但是這實際上也是不行的。就比如系統中的財務模塊,假定模塊中含有報銷頁面和申報頁面,如果按照模塊進行拆分,那麼肯定有用戶同時包含了兩個互斥功能。根據1和2,我們需要按照最小化進行權限劃分。但是這個也是值得商榷的,因為不同系統,最小的權限劃分對於提供的功能來說,劃分的角度也是不同的。數據抽象原則“最小特權劃分”從某個程度上來說決定了“最小特權”和“數據抽象”分別決定了權限中控制的對象和操作,但是這裡面還差了一個角度,則是現階段非常普遍的前後端分離的權限劃分的問題。
服務端的權限前後端分離下的服務端,本質而言只是提供接口的或者rpc服務等其他資源服務的服務提供方。服務端能提供的權限的鑑權機制的對象:接口服務(api或者其他形式的服務)在前後端已經分離的情況下,服務端對於前端而言只是接口的提供者,但無權干涉前端頁面的展示,服務端對於前端而言,能提供的是僅鑑權服務的接口而已,但是頁面的構成,頁面的欄目菜單或頁面內的功能點的構成均由前端單獨完成的。
前端或移動端的權限前端的鑑權包含頁面的可訪問,和頁面上的某項功能按鈕是否可以操作。前端和移動端的服務對象是用戶,提供的服務是可視化的頁面。前後端的服務對象的責任劃分清晰之後,我們就不會混雜權限的歸屬的問題,在過去前後端沒分離的情況下,頁面本身就是服務端的一體,就沒有這方面的問題。雖然分清楚了各端本質提供的服務的情況,但是前後端分離的權限劃分中仍有新的問題。
因為服務端和前端的鑑權對象不一致,服務端只能鑑權到api接口,那麼是否將api接口和前端的頁面乃至頁面功能點進行數據庫表與表層面的綁定關係。如果進行了進行了表與表之間的綁定關係,那麼整個權限系統的維護量,是否能在能承受範圍之內。如果不進行表與表之間的綁定關係,前端頁面在操作功能的時候,服務端如何鑑權頁面調用的api接口是否在用戶可操作的權限之內?其實上面的問題則需要一個取捨,要麼增加運維成本嚴格控制前端調用api接口的關係,偏重服務端的接口服務鑑權。要麼是給api接口和前端頁面及功能點再提供一個通性的邏輯判斷處理,如:頁面及調用的功能點屬於某個業務模塊的操作許可,而頁面觸發的接口也剛好是這個業務模塊的操作許可,那麼鑑權通過,否則鑑權失敗。這種就是屬於側重前端對於用戶的控制,弱化了接口級的控制。
3.角色與權限的關係
通過1,2的描述,基本確定了權限的定義和劃分一個權限的通用法則。用戶在系統中最終是通過權限來使用各種功能點,是否有必要在用戶和權限中間再額外的附加一個關係。在我們現在的權限設計中,是增加了這樣一層關係的,就是角色。
減少操作層面的重複性。角色其實就是一組權限的集合,是權限集合的更高級抽象,為了便於運維和實際管理,通過角色的賦予,替代了權限賦予用戶的繁瑣性,在一套系統中,普遍情況都是權限的數量多於角色的數量。權限是控制對象和操作集合,它本身不存在任何狀態,但是在賦予在用戶身上則擁有了狀態,比如權限A中允許用戶訪問頁面A,權限B允許用戶訪問頁面B,權限D運行用戶訪問B頁面,但是不允許訪問A頁面。那麼這層關係的維護在角色層面的話,會更加清晰,也就是說本身角色具有權限集合組裝的策略問題,對於互斥的權限有不同的方案處理。(權限中沒有某個操作和權限中禁止某個操作,是兩個不同的角度,不能混為一談)因為權限的可能存在互斥性,在實際業務中也會引發角色的互斥性,舉一個現實中的案例來解釋互斥性:張三是軟件部的負責人但因為工作的特殊性也同樣隸屬於業務部的普通員工,我們設定負責人是可以要求人事部門給本部門進行招聘的,在實際的情況中,張三能給軟件部招聘新員工,但是不能給業務部招聘員工。我們把這個案例運用在系統中,張三則是擁有負責人和普通員工兩個角色,但是招聘的功能如果不加以控制,則會發生張三給業務部招人的結果。於是為了解決角色的這類問題,引入了職責劃分的方案。職責劃分分為:靜態、動態。所謂靜態職責劃分則是在角色創建之初就已經確定了角色的職責內容。動態職責劃分是系統運行過程中對用戶已有的角色進行控制,例如:某些角色不能共存在用戶身上(引入角色的概念後,實際上這已經是一個比較完整的RBAC的權限設計的模型了。
4.數據表的設計思路
根據3的結論,實質上已經有了一個基礎的表設計的雛形。在這裡就有一些值得注意的點。
5.安全框架
由於我們是基於RBAC的權限設計,現行java框架下最常見的就是shiro和Spring Security 。這兩個就是仁者見仁智者見智了,我兩者都實用過。僅建議使用shiro的話,可以更好的理解RBAC的設計思路,Spring Security 也是個不錯的框架,但是它涉及到的概念太多,並不利於初學者去了解最基本的權限設計。我在這隻在學習的角度上去比較這兩個框架,並沒有再其他領域去做比較,也不去比較。
引用的文章《權限系統與RBAC模型概述[絕對經典]》
本文由開源作者cross___原創,© 著作權歸作者所有,如有侵權請聯繫刪除,