擴充RBAC使用者角色許可權設計方案<轉>

來源:互聯網
上載者:User

標籤:blog   http   io   ar   檔案   資料   html   log   sp   

RBAC(Role-Based Access Control,角色型存取控制),就是使用者通過角色與許可權進行關聯。簡單地說,一個使用者擁有若干角色,每一個角色擁有若干許可權。這樣,就構造成“使用者-角色-許可權”的授權模型。在這種模型中,使用者與角色之間,角色與許可權之間,一般者是多對多的關係。(如)

角色是什嗎?可以理解為一定數量的許可權的集合,許可權的載體。例如:一個論壇系統,“超級管理員”、“版主”都是角色。版主可管理版內的文章、可管理版內的使用者等,這些是許可權。要給某個使用者授予這些許可權,不需要直接將許可權授予使用者,可將“版主”這個角色賦予該使用者。

當使用者的數量非常大時,要給系統每個使用者逐一授權(授角色),是件非常煩瑣的事情。這時,就需要給使用者分組,每個使用者組內有多個使用者。除了可給使用者授權外,還可以給使用者組授權。這樣一來,使用者擁有的所有許可權,就是使用者個人擁有的許可權與該使用者所在使用者組擁有的許可權之和。(為使用者組、使用者與角色三者的關聯關係)

在應用系統中,許可權表現成什嗎?對功能模組的操作,對上傳檔案的刪改,菜單的訪問,甚至頁面上某個按鈕、某個圖片的可見度控制,都可屬於許可權的範疇。有些許可權設計,會把功能操作作為一類,而把檔案、菜單、頁面元素等作為另一類,這樣構成“使用者-角色-許可權-資源”的授權模型。而在做資料表建模時,可把功能操作和資源統一管理,也就是都直接與許可權表進行關聯,這樣可能更具便捷性和易擴充性。(見)

請留意許可權表中有一列“權限類別型”,我們根據它的取值來區分是哪一類許可權,如“MENU”表示菜單的存取權限、“OPERATION”表示功能模組的操作許可權、“FILE”表示檔案的修改許可權、“ELEMENT”表示頁面元素的可見度控制等。

這樣設計的好處有二。其一,不需要區分哪些是許可權操作,哪些是資源,(實際上,有時候也不好區分,如菜單,把它理解為資源呢還是功能模組許可權呢?)。其二,方便擴充,當系統要對新的東西進行許可權控制時,我只需要建立一個新的關聯表“許可權XX關聯表”,並確定這類許可權的權限類別型字串。

這裡要注意的是,許可權表與許可權菜單關聯表、許可權菜單關聯表與菜單表都是一對一的關係。(檔案、頁面許可權點、功能操作等同理)。也就是每添加一個菜單,就得同時往這三個表中各插入一條記錄。這樣,可以不需要許可權菜單關聯表,讓許可權表與菜單表直接關聯,此時,須在許可權表中新增一列用來儲存菜單的ID,許可權表通過“權限類別型”和這個ID來區分是種類型下的哪條記錄。

到這裡,RBAC許可權模型的擴充模型的完整設計圖如下:

隨著系統的日益龐大,為了方便管理,可引入角色群組對角色進行分類管理,跟使用者組不同,角色群組不參與授權。例如:某電網系統的許可權管理模組中,角色就是掛在區局下,而區局在這裡可當作角色群組,它不參於許可權分配。另外,為方便上面各主表自身的管理與尋找,可採用樹型結構,如菜單樹、功能樹等,當然這些可不需要參於許可權分配。

轉自 http://www.cnblogs.com/zwq194/archive/2011/03/07/1974821.html

擴充RBAC使用者角色許可權設計方案<轉>

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.