許可權管理 許可權模型和許可權控制

2021-07-15 02:05:58 字數 1255 閱讀 7673

等我接收許可權的時候,許可權模型和表已經定好了的,我也只是帶領大家開發功能。不過還是要囉嗦一下許可權模型的初始化和進化狀態。

上篇部落格也說過資源是通過許可權或者是許可來控制的。所以如下圖:

主體(賬號、密碼)

資源(資源名稱、訪問位址)

許可權(許可權名稱、資源id)

角色(角色名稱)

角色和許可權關係(角色

id、許可權id)

主體和角色關係(主體

id、角色id)

進化模型:

通常企業開發是把資源和許可權表合為一張許可權表的。

資源(資源名稱、訪問位址)

許可權(許可權名稱、資源id)

合併為:

許可權(許可權名稱、資源名稱、資源訪問位址)

此進化模型被稱為許可權管理的通用模型,甚至還有些會對通用模型進行修改。

使用者需要分配相應的許可權才可以訪問相應的資源,通常給使用者分配資源許可權需要將許可權資訊持久化,比如儲存在關聯式資料庫中。分配許可權就引出了許可權控制。有兩種許可權控制方式。

基於角色的訪問控制,又叫

rbac

(role based access control

),比如系統中角色包括:學生、教師、教學秘書、管理員等(角色針對使用者來劃分)。

系統中**實現:

//判斷使用者屬於哪個角色

if(user.role=="教學秘書")

問題:角色是針對人劃分的,如果該角色可以訪問的資源出現變更,那就需要修改**,比如角色名稱修改,或者角色可用的資源許可權修改,那**就需要修改,這樣是非常不人性化的,也破壞了**的完整性,擴充套件性不強,不利於系統維護。

基於資源的訪問控制,也簡稱為

rbac

(resourcebased access control

),資源在系統中是不變的,比如

itoo

中資源有各個子系統、各個系統的模組、各個模組下的頁面、按鈕等。

if(user.haspermission ('分配資源(許可權識別符號)'))
這個方法就可以解決使用者角色變更不用再修改**的問題了,如果資源變更,那只需要給角色對應的資源變更就可以了。所以建議使用基於資源的訪問控制實現許可權管理。

TrustedInstaller管理許可權

trustedinstaller.exe實際上是 windows modules installer 這個服務的程序,路徑位於c windows servicing trustedinstaller.exe。當進行windows update,或者安裝某些微軟發布的安裝包時,windows modu...

Liunx 管理許可權

1.acl許可權 acl access control list 用來設定使用者 除所有者,所屬組,其他組之外的使用者或組 針對檔案的讀 寫 執行許可權。getfacl 檔名 檢視acl許可權 setfacl 選項 檔名 設定acl許可權選項 舉例 我們要求 root 是 acltest 目錄的屬主...

3 管理許可權

授予物件許可權 在oracle9i前,授予物件許可權是由物件的所有者來完成的,如果用其它的使用者來操作,則需要使用者具有相應的 with grant option 許可權,從oracle9i開始,dba,sys,system 可以將任何物件上的物件許可權授予其它使用者.授予物件許可權是用grant命...