RBAC 基於角色的許可權訪問控制
基於角色的許可權訪問控制(Role-Based Access Control)作為傳統訪問控制(自主訪問,強制訪問)的有前景的代替受到廣泛的關注。在RBAC中,許可權與角色相關聯,使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組織中,角色是為了完成各種工作而創造,使用者則依據它的責任和資格來被指派相應的角色,使用者可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合併而賦予新的許可權,而許可權也可根據需要而從某角色中回收。角色與角色的關係可以建立起來以囊括更廣泛的客觀情況。
1.簡介
RBAC支援三個著名的安全原則:最小許可權原則,責任分離原則和資料抽象原則
- 最小許可權原則之所以被RBAC所支援,是因為RBAC可以將其角色配置成其完成任務所需要的最小的許可權集。
- 責任分離原則可以通過呼叫相互獨立互斥的角色來共同完成敏感的任務而體現,比如要求一個計帳員和財務管理員共參與同一過帳。
- 資料抽象可以通過許可權的抽象來體現,如財務操作用借款、存款等抽象許可權,而不用作業系統提供的典型的讀、寫、執行許可權。然而這些原則必須通過RBAC各部件的詳細配置才能得以體現。、
RBAC有許多部件(BUCU),這使得RBAC的管理多面化。尤其是,我們要分割這些問題來討論:使用者與角色的指派;角色與許可權的指派;為定義角色的繼承進行的角色與角色的指派。這些活動都要求把使用者和許可權聯絡起來。然而在很多情況下它們最好由不同的管理員或
2.基本概念
- RBAC認為許可權授權實際上是Who、What、How的問題。在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系統中,User實際上是在扮演角色(Role),可以用Actor來取代User,這個想法來自於Business Modeling With UML一書Actor-Role模式。考慮到多人可以有相同許可權,RBAC引入了Group的概念。Group同樣也看作是Actor。而User的概念就具象到一個人。
- 這裡的Group和GBAC(Group-Based Access Control)中的Group(組)不同。GBAC多用於作業系統中。其中的Group直接和許可權相關聯,實際上RBAC也借鑑了一些GBAC的概念。
- Group和User都和組織機構有關,但不是組織機構。二者在概念上是不同的。組織機構是物理存在的公司結構的抽象模型,包括部門,人,職位等等,而許可權模型是對抽象概念描述。組織結構一般用Martin fowler的Party或責任模式來建模。
- Party模式中的Person和User的關係,是每個Person可以對應到一個User,但可能不是所有的User都有對應的Person。Party中的部門Department或組織Organization,都可以對應到Group。反之Group未必對應一個實際的機構。例如,可以有副經理這個Group,這是多人有相同職責。
- 引入Group這個概念,除了用來解決多人相同角色問題外,還用以解決組織機構的另一種授權問題:例如,A部門的新聞我希望所有的A部門的人都能看。有了這樣一個A部門對應的Group,就可直接授權給這個Group。
相關推薦
RBAC(基於角色的訪問控制)-許可權設計
RBAC(Role Based Access Control)基於角色的訪問控制.RBAC0是RBAC的核心,主要有四部分組成:1、使用者(User)2、角色(Role)3、許可(Permission)4、會話(Session)RBAC2是RBAC的約束模型RBAC(Role
基於角色的訪問控制 (RBAC)許可權管理
許可權針對的物件或資源(Resource、Class)。 How:具體的許可權(Privilege,正向授權與負向授權)。 Operator:操作。表明對What的How操作。也就是Privilege+Resource Role:角色,一定數量的許可權的集合。許可
【基於角色的訪問控制RBAC】許可權與資源樹
基於角色的許可權訪問控制(Role-BasedAccess Control)。在RBAC中,許可權與角色相關聯,通過使使用者成為適當的角色而得到這些角色的許可權。使用者可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合併而賦予新的許可權,而許可權也可根據需要而從某角色中回
Azure ARM (16) 基於角色的訪問控制 (Role Based Access Control, RBAC) - 使用默認的Role
not 問控制 https 所有 嘗試 介紹 admin ima 服務管理 《Windows Azure Platform 系列文章目錄》 今天上午剛剛和客戶溝通過,趁熱打鐵寫一篇Blog。 熟悉Microsoft Azure平臺的讀者都知道,在
Azure ARM (17) 基於角色的訪問控制 (Role Based Access Control, RBAC) - 自定義Role
結果 del role environ db4 lis sele logs ini 《Windows Azure Platform 系列文章目錄》 在上面一篇博客中,筆者介紹了如何在RBAC裏面,設置默認的Role。 這裏筆者將介紹如何使用自定的Ro
基於角色的訪問控制RBAC的mysql表設計
一、使用者角色表,用於儲存角色id和角色名稱,表結構如下: create table roles( role_id int unsigned not null auto_increment, r
初識ASP.NET MVC窗體驗證與許可權過濾---2.基於角色的訪問控制
上一篇完成了窗體身份驗證並在客戶端儲存了鑑權cookies,系統已經知道我已經登入並獲得了授權。但僅僅知道登入了是不夠的,還要對能夠訪問的區域做出控制。男人不能進女廁所,女人不能進男廁所O(∩_∩)O哈哈~ 這裡就要來扯一扯AOP了,
RBAC 基於角色的訪問控制權限
Design Within an organization, roles are created for various job functions. The permissions to perform certain operations are assig
RBAC基於角色許可權分配問題中的(父許可權選中同時子許可權全部選中,選中子許可權時父許可權也隨之選中效果)
說明:以下程式碼是在thinkphp5.2版本下程式設計. 實現功能:父許可權選中同時子許可權全部選中,選中子許可權時父許可權也隨之選中 解決方式: 一 . 前端通過給多選框設定onchange事件,通過ajax向後端發起請求(傳遞id), 二 . 後端通過ID獲取子分類
.Net平臺下基於角色的訪問控制系統(轉)
基於角色的使用者許可權管理系統(RBAC)基本理論[1][2] RBAC是目前公認的解決大型企業的統一資源訪問控制的有效方法。其顯著的兩大特徵是:一是減小授權管理的複雜性,降低管理開銷;二是靈活地支援企業的安全策略,並對企業的變化有很大的伸縮性。 資源是應用系統中被管理、
idou老師教你學istio 21:基於角色的訪問控制
權限 mar index acc def review 允許 .html mark istio的授權功能,也稱為基於角色的訪問控制(RBAC),它為istio服務網格中的服務提供命名空間級別、服務級別和方法級別的訪問控制。基於角色的訪問控制具有簡單易用、靈活和高性能等特性。
.Net Core實戰之基於角色的訪問控制的設計
前言 上個月,我寫了兩篇微服務的文章:《.Net微服務實戰之技術架構分層篇》與《.Net微服務實戰之技術選型篇》,微服務系列原有三篇,當我憋第三篇的內容時候一直沒有靈感,因此先打算放一放。 本篇文章與原始碼原本打算實在去年的時候完成併發布的,然而我一直忙於公司專案的微服務的實施,所以該篇文章一拖再拖。
基於角色的許可權訪問控制(RBAC-Java)
業務場景 許可權管理類的網站會存在一個定製化的業務需求,不同的使用者擁有不同的功能介面、不同的業務許可權.從專案角度來描述就是不同的使用者擁有不同的角色,不同的角色綁定了不同的功能模組,並且要保證使用者不能操作許可權之外的功能。基於這樣的出發點可以考慮建立一套
RBAC 基於角色的許可權訪問控制
基於角色的許可權訪問控制(Role-Based Access Control)作為傳統訪問控制(自主訪問,強制訪問)的有前景的代替受到廣泛的關注。在RBAC中,許可權與角色相關聯,使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組
RBAC基於角色的許可權控制個人理解
基本上搞過it的都知道許可權控制其實是很麻煩的一件事情,但是不難理解。在我學習rbac之前,對許可權的理解基本上就是許可權分配給角色,角色又分配給使用者組,然後使用者可以屬於使用者組之類的。一些企業級應用可能會有更復雜的情況,比如A部門的員工甲,就分配A角色給甲;若甲在B部
rbac基於角色的權限控制組件目錄
div 頁面 動態數據 登入 ESS 寫入 tps 組件 class 權限組件之表設計 權限組件之錄入數據 權限組件之獲取登入用戶的所有權限 權限組件之將登錄用戶權限寫入到session中 session源碼 權限組件之粒度到按鈕級別1
Yii2基於角色的訪問控制權限RBAC表結構原理分析
這裡有幾個概念很重要 許可權: 就是指使用者是否可以執行哪些操作。 如:小張可以發帖、回帖、瀏覽,小紅只能回帖、瀏覽角色: 就是上面說的一組操作的集合。 如:高階會員有發帖、回帖、刪貼、瀏覽的許可權,普通會員只有回帖、瀏覽的許可權。 比如小張是高階會員,那麼他就可以執行發帖
rbac基於角色的許可權管理開發
一、model模組 許可權表結構設計: from django.db import models class User(models.Model): """ 使用者表 """ username =
簡單的RBAC基於角色的使用者許可權的實現
RBAC基於角色的使用者許可權在實際應用中廣泛使用,尤其是在複雜的多使用者環境下,同一個後臺會用不同角色的使用者,而每個角色使用者所擁有的操作許可權是不同的,RBAC巧妙的解決了這個問題: 這裡先介紹下以前用到過的,THinkphp中內建了RBAC解決方案,這裡不再多說簡
Nginx實現基於ip的訪問控制(Ngx_http_access_module模塊)
nginx;web服務器;Nginx實現基於ip的訪問控制功能:(Ngx_http_access_module)官方文檔:http://nginx.org/en/docs/http/ngx_http_access_module.html官方示例:The ngx_http_access_module modul