關於python實現rbac的信息

本文目錄一覽：

• 1、許可權管理（RBAC）
• 2、請教關於RBAC許可權管理
• 3、B端產品之許可權設計（RBAC許可權模型）

許可權管理（RBAC）

轉自：（忘了）

RBAC支持三個著名的安全原則：最小許可權原則，責任分離原則和數據抽象原則。

RBAC的基本思想是：授權給用戶的訪問許可權，通常由用戶在一個組織中擔當的角色來確定。

RBAC中許可被授權給角色，角色被授權給用戶，用戶不直接與許可關聯。

RBAC對訪問許可權的授權由管理員統一管理，RBAC根據用戶在組織內所處的角色作出訪問授權與控制，授權規定是強加給用戶的，用戶不能自主地將訪問許可權傳給他人，這是一種非自主型集中式訪問控制方式。

例如，在醫院裡，醫生這個角色可以開處方，但他無權將開處方的權力傳給護士。在RBAC中，用戶標識對於身份認證以及審計記錄是十分有用的；但真正決定訪問許可權的是用戶對應的角色標識。用戶能夠對一客體執行訪問操作的必要條件是，該用戶被授權了一定的角色，其中有一個在當前時刻處於活躍狀態，而且這個角色對客體擁有相應的訪問許可權。即RBAC以角色作為訪問控制的主體，用戶以什麼樣的角色對資源進行訪問，決定了用戶可執行何種操作。

在RBAC模型中，who、what、how構成了訪問許可權三元組,也就是「Who對What(Which)進行How的操作」。

Who：許可權的擁用者或主體（如Principal、User、Group、Role、Actor等等）

What：許可權針對的對象或資源（Resource、Class）。

How：具體的許可權（Privilege,正向授權與負向授權）。

Operator：操作。表明對What的How操作。也就是Privilege+Resource

Role：角色，一定數量的許可權的集合。許可權分配的單位與載體,目的是隔離User與Privilege的邏輯關係.

Group：用戶組，許可權分配的單位與載體。許可權不考慮分配給特定的用戶而給組。組可以包括組(以實現許可權的繼承)，也可以包含用戶，組內用戶繼承組的許可權。User與Group是多對多的關係。Group可以層次化，以滿足不同層級許可權控制的要求。

RBAC的關注點在於Role和User, Permission的關係。稱為User assignment(UA)和Permission assignment(PA).關係的左右兩邊都是Many-to-Many關係。就是user可以有多個role，role可以包括多個user。凡是用過RDBMS都知道，n:m 的關係需要一個中間表來保存兩個表的關係。這UA和PA就相當於中間表。事實上，整個RBAC都是基於關係模型。

Session在RBAC中是比較隱晦的一個元素。標準上說：每個Session是一個映射，一個用戶到多個role的映射。當一個用戶激活他所有角色的一個子集的時候，建立一個session。每個Session和單個的user關聯，並且每個User可以關聯到一或多個Session.

請教關於RBAC許可權管理

禁止的許可權規則集

如果許可權規則不是一個集合，因為只有與用戶或角色關聯的許可權規則才允許訪問，所以用戶的許可權是一個閉合區域，不想用戶擁有某些許可權時，只要不進行關聯授權即可。如果許可權規則使用通配符變成一個集合，那麼用戶的許可權將變成一個開放區域，比如上面的論壇文章列表，假設論壇文章按照「版面/作者/文章標題」作為資源命名，那麼將(閱覽, 版面/作者/*)授權給某用戶時，該用戶允許閱覽該版面下該作者的所有文章，假設現在有一種管理需求要求某用戶可以閱覽某版面下某作者除某幾種文章標題外的所有文章，這樣單純的允許授權難以實現這個管理需求。

法律有許可和禁止的區別，那麼許可權管理也應該有許可和禁止兩種授權，上面的不允許訪問某幾種文章標題的文章就是一種禁止規則，如果將這種禁止規則合併到允許規則中，就可以解決上面的問題。這就相當於畫了一個大圈表示可以訪問的區域，但是大圈裡面的某些小圈是不可以訪問的區域。這又帶來一個問題，假設允許的和禁止的規則重疊，以誰為準？這個沒有一個準則，不過基於安全性考慮，應該採用禁止優先，只要是禁止的集合，就算有允許的集合重疊，也不允許訪問。

提高許可權驗證效率

使用關係資料庫存儲許可權數據時，許可權數據表更新和查詢的操作頻繁度通常小於1:9，也就是這是一個典型的OLAP系統，以查詢為主，所以可以採用OLAP的優化策略進行優化，但是大多數優化策略都不具備實時性，如果兼顧實時性和效率要求，可以單獨創建一個內存資料庫，這個內存資料庫只存放用戶、資源、操作關聯關係，也就是(用戶, 操作, 資源)集合，如果用戶通過角色關聯到許可權規則，那麼將這些用戶到許可權規則的間接傳遞關係轉變成直接傳遞關係保存。這個內存資料庫就相當於許可權數據的緩存，可以保證很高的查詢效率，並且該內存資料庫與許可權管理保持同步，可以保證實時性。

安裝和配置

附件是許可權管理和許可權驗證的實現，也有用戶管理的演示，不過用戶管理很粗糙，實際使用需要做進一步開發，之所以沒有開發相對完善的用戶管理，是因為現在已有的系統通常都有完善的用戶管理。

下面簡單講解安裝配置，只在Tomcat5523+MySQL5037+jre1.5.0_12下測試過。

1． 下載rbac+profile.rar，解壓，得到一系列文件，文件用途如下：

profile.admin.src.v1.jar 用戶管理源代碼

rbac.admin.src.v2.jar 許可權管理源代碼

rbac.auth.src.v2.jar 許可權驗證源代碼

profile.v1.MySQL5.sql 用戶管理用戶數據表

profile.war 用戶管理WEB系統

rbac.v2.MySQL5.sql 許可權管理數據表

rbac.war 許可權管理WEB系統

2． 創建資料庫profile，使用UTF-8導入profile.v1.MySQL5.sql到profile，使用下面SQL創建用戶root/1：

Insert into T_PROFILE(USER_ID, USER_NAME, USER_PASSWORD) values(『1』, 『root』, sha1(『1』));

如果創建過先前SSO單點登陸的用戶數據表，可以跳過這步，使用先前的數據表。

3． 創建資料庫rbac，使用UTF-8導入rbac.v2.MySQL5.sql到rbac。

4． 拷貝profile.war和rbac.war到Tomcat5523/webapps/，會自動生成profile和rbac目錄。

5． 參考配置單點登陸，因為許可權管理和用戶管理需要依賴單點登陸。

6． 下載相關依賴Java庫：

下載cglib最新版本，拷貝asm.jar和cglib-2.1.3.jar到Tomcat/shared/lib。

下載c3p0最新版本，拷貝c3p0-0.9.1.1.jar到Tomcat/shared/lib。

下載mysql-connector最新版本，拷貝mysql-connector-java-5.0.4-bin.jar到Tomcat/shared/lib。

下載dwr最新版本，拷貝dwr2.0.1.jar到Tomcat/shared/lib。

7． 打開profile/ WEB-INF/classes/的rbac_auth.properties、sso_agent.properties、profile_admin.properties。

# 修改為合適配置

# rbac_auth.properties

rbac.auth.db.ds.c3p0.url=jdbc:mysql://localhost/rbac

rbac.auth.db.ds.c3p0.user=root

rbac.auth.db.ds.c3p0.password=1

# sso_agent.properties

sso.passport.login=

sso.passport.logout=

# profile_admin.properties

profile.admin.db.ds.c3p0.url=jdbc:mysql://localhost/profile

profile.admin.db.ds.c3p0.user=root

profile.admin.db.ds.c3p0.password=1

8． 打開rbac/WEB-INF/classes/下的rbac_admin.properties、rbac_auth.properties、sso_agent.properties。

# 修改為合適配置

# rbac_auth.properties

rbac.auth.db.ds.c3p0.url=jdbc:mysql://localhost/rbac

rbac.auth.db.ds.c3p0.user=root

rbac.auth.db.ds.c3p0.password=1

# sso_agent.properties

sso.passport.login=

sso.passport.logout=

# rbac_admin.properties

rbac.admin.profile.explorer=?

rbac.admin.profile.profile=?

rbac.admin.db.rbac.ds.c3p0.url=jdbc:mysql://localhost/rbac

rbac.admin.db.rbac.ds.c3p0.user=root

rbac.admin.db.rbac.ds.c3p0.password=1

B端產品之許可權設計（RBAC許可權模型）

一、前言

隨著互聯網的快速發展，B端行業也逐漸崛起，很多企業管理中使用的軟體我們通常稱其為B端管理系統，而在B端系統中「許可權管理」是必不可少的功能，不同的系統中許可權的應用複雜程度不一樣，都是根據實際產品以及需求情況而設置合理的許可權。而我們現在對於許可權的設置基本上都是建立在RBAC許可權模型上的、擴展的，下面我會通過介紹RBAC許可權模型的概念以及結合實際業務情況列舉許可權設置的應用。

二、什麼是RBAC許可權模型？

RBAC是Role-BasedAccess Control的英文縮寫，意思是基於角色的訪問控制。RBAC認為許可權授權實際上是Who、What、How的問題。在RBAC模型中，who、what、how構成了訪問許可權三元組，也就是「Who對What進行How的操作，也就是「主體」對「客體」的操作。其中who是許可權的擁有者或主體（例如：User、Role），what是資源或對象（Resource、Class)。

簡單的理解其理念就是將「角色」這個概念賦予用戶，在系統中用戶與許可權之間通過角色進行關聯，以這樣的方法來實現靈活配置。

RBAC其實是一種分析模型，主要分為：基本模型RBAC0、角色分層模型RBAC1、角色限制模型RBAC2和統一模型RBAC3。

RBAC許可權模型是基於角色的許可權控制。模型中有幾個關鍵的術語：

用戶：系統介面及訪問的操作者

許可權：能夠訪問某介面或者做某操作的授權資格

角色：具有一類相同操作許可權的用戶的總稱

1）RBAC0

RBAC0是RBAC許可權模型的核心思想，RBAC1、RBAC2、RBAC3都是在RBAC0上進行擴展的。RBAC0是由四部分構成：用戶、角色、會話、許可。用戶和角色的含義很簡單，通過字面意思即可明白，會話：指用戶被賦予角色的過程，稱之為會話或者是說激活角色；許可： 就是角色擁有的許可權（操作和和被控制的對象），簡單的說就是用戶可使用的功能或者可查看的數據。

用戶與角色是多對多的關係，用戶與會話是一對一的關係，會話與角色是一對多的關係，角色與許可是多對多的關係。

2）RBAC1

RBAC1是在RBAC0許可權模型的基礎上，在角色中加入了繼承的概念，添加了繼承發的概念後，角色就有了上下級或者等級關係。

舉例：集團權責清單下包含的角色有：系統管理員、總部權責管理員、區域權責管理員、普通用戶，當管理方式向下兼容時，就可以採用RBAC1的繼承關係來實現許可權的設置。上層角色擁有下層的所有角色的許可權，且上層角色可擁有額外的許可權

3）RBAC2

RBAC2是在RBAC0許可權模型的基礎上，在用戶和角色以及會話和角色之間分別加入了約束的概念（職責分離），職責分離指的是同一個人不能擁有兩種特定的許可權（例如財務部的納入和支出，或者運動員和裁判員等等）。

用戶和角色的約束有以下幾種形式:

互斥角色：同一個用戶在兩個互斥角色中只能選擇一個（也會存在一個用戶擁有多個角色情況，但是需要通過切換用戶角色來實現對不同業務操作）

基數約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的

先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色

會話和角色之間的約束，可以動態的約束用戶擁有的角色，例如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。

例如：iconfont和藍湖的用戶與角色就採用了約束的概念，超級管理員只允許只有一個

4）RBAC3

RBAC3是RBAC1與RBAC2的合集，所以RBAC3包含繼承和約束。

二、為什麼要引用RBAC許可權模型？

RBAC中具有角色的概念，如果沒有角色這個概念，那麼在系統中，每個用戶都需要單獨設置許可權，而系統中所涉及到的功能許可權和數據許可權都非常多，每個用戶都單獨設置許可權對於維護許可權的管理員來說無疑是一件繁瑣且工作量巨大的任務。

而引入角色這個概念後，我們只需要給系統設置不同的角色， 給角色賦予許可權，再將用戶與角色關聯，這樣用戶所關聯的角色就直接擁有了該角色下的所有許可權。

例如：用戶1~用戶8分別擁有以下許可權，，不同用戶具有相同許可權的我用不同的顏色做了區分，如下圖：

在沒有引入RBAC許可權模型的情況下，用戶與許可權的關係圖可採用下圖的楊叔叔展示，每個用戶分別設置對應的許可權，即便是具有相同許可權的用戶也需要多次設置許可權。

引入RBAC許可權模型及引入了角色的概念，根據上面表格的統計，用戶1、用戶3、用戶5、用戶8擁有的許可權相同，用戶2、用戶6、用戶7擁有相同的許可權，用戶4是獨立的許可權，所以我們這裡可以根據數據統計，以及實際的需求情況，可以建立三個不同的角色，角色A、角色B、角色C，三個角色分別對應三組用戶不同的許可權，如下圖所示：

對應的上面的案例表格我們就可以調整為含有角色列的數據表，這樣便可以清楚的知道每個用戶所對應的角色及許可權。

通過引用RBAC許可權模型後，對於系統中大量的用戶的許可權設置可以更好的建立管理，角色的引入讓具有相同許可權的用戶可以統一關聯到相同的的角色中，這樣只需要在系統中設置一次角色的許可權，後續的用戶便可以直接關聯這些角色，這樣就省去了重複設置許可權的過程，對於大型平台的應用上，用戶的數量成千上萬，這樣就可避免在設置許可權這項工作上浪費大量的時間。

三、引入用戶組的概念

我們依舊拿上面表格案例舉例，雖然前面我們應用的RBAC許可權模型的概念，但是對於大量用戶擁有相同許可權的用戶，我們同樣的也需要對每個用戶設置對應的角色，如果一個部門上萬人，那麼我們就需要給這個部門上萬人分別設置角色，而這上萬其實是具有相同的許可權的，如果直接採用基礎的RBAC許可權模型的話，那麼面對這樣的情況，無疑也是具有一個龐大的重複的工作量，並且也不利於後期用戶變更的維護管理，那麼針對相同用戶具有相同的許可權的情況，我們便可以引入用戶組的概念。

什麼是用戶組呢？ 用戶組：把具有相同角色的用戶進行分類。

上面我們的數據表格案例中的用戶1、用戶3、用戶5、用戶8具有相同的角色A，用戶2、用戶6、用戶7也擁有相同的角色B，那麼我們就可以將這些具有相同角色的用戶建立用戶組的關係，拿上面的案例，我們分別對相同角色的用戶建立組關係，如下：

用戶1、用戶3、用戶5、用戶8→建立用戶組1

用戶2、用戶6、用戶7→建立用戶組2

因為用戶4隻有一個用戶，所以直接還是單獨建立用戶與角色的關係，不需要建立用戶組，當然儘管只有一個用戶也是可以建立用戶組的關係，這樣有利於後期其他用戶與用於4具有相同的角色時，就可以直接將其他用戶添加到這個用戶組下即可，根據業務的實際情況而選擇適合的方案即可。

通過案例表格的變化我們就可以直觀的看出許可權設置變得清晰簡潔了，通過第用戶組賦予角色，可以減少大量的重複的工作，我們常見的企業組織、部門下經常會出現不同用戶具有相同角色的情況，所以採用用戶組的方式，便可以很好的解決這個問題，給具有相同許可權的用戶建立用戶組，將用戶組關聯到對應的角色下，此用戶組就擁有了此角色下的所有許可權，而用戶是屬於用戶組的，所以用戶組下的所有用戶也就同樣的擁有了此角色下的所有許可權。一個用戶可以屬於多個用戶組，一個用戶組也可以包括多個用戶，所以用戶與用戶組是多對多的關係。

四、引入許可權組的概念

許可權組與用戶組的原理差不多，是將一些相對固定的功能或者許可權建立組的關係，然後再給此許可權組賦予角色，目前我所接觸的B端項目中使用許可權組的概念的比較少，可簡單的看一下關係圖

四、功能許可權和數據許可權

B端系統中一般產品的許可權由頁面、操作和數據構成。頁面與操作相互關聯，必須擁有頁面許可權，才能分配該頁面下對應的操作許可權，數據可被增刪改查。所以將許可權管理分為 功能許可權管理和數據許可權管理。

功能許可權管理：指的是用戶可看到那些模塊，能操作那些按鈕，因為企業中的用戶擁有不同的角色，擁有的職責也是不同的。

數據許可權管理：指的是用戶可看到哪些模塊的哪些數據。

例如：一個系統中包含多個權責清單（清單1、清單2、清單3），系統管理員能對整個系統操作維護。。。。。

完整內容請查看公眾號原文鏈接

原文鏈接：B端產品之許可權設計（RBAC許可權模型）

來源公眾號《設計小余》