我想了解基於RBAC模型的訪問控制。我提到了以下鏈接。在基於角色的訪問控制（RBAC）中使用會話
我作爲摘錄提到沒有清楚地理解這部分 -
*「每個會話是一個用戶的映射可能是多個角色，即用戶在建立會話用戶激活他或她所分配的角色的一些子集，每個會話與一個用戶相關聯，並且每個用戶與一個或多個會話相關聯，函數session_roles爲我們提供了由會話激活的角色，並且函數user_sessions給出了我們是與用戶相關聯的一組會話。用戶可用的權限是分配給角色ac的權限「*
問題 - 如何使用會話來激活角色？用戶/組和角色之間的關係作爲管理數據插入。那麼，會話如何爲用戶激活角色的子集？
P.S - >我之前問過這個問題here但沒有答案。可能是這個問題太基本，不能問，但我很想理解它。任何用例或鏈接肯定會有所幫助。
謝謝你的時間。
在RBAC中，管理員通過將角色分配給角色來給予權限，並通過爲用戶分配角色來給予權限。正如您所知道的，爲了使用戶能夠使用特定的權限，他必須被分配至少一個提供所述解決方案的角色。
所以每個用戶都有一套分配給他的角色。在會話期間，他可以選擇激活（或停用）任何這些角色，但不能選擇其他角色。激活的角色確定在會話期間給定時間哪些權限可供用戶使用。例如，這對於職責約束的動態分離是有用的，其中兩個角色A和B可以分配給同一用戶U但不能一起使用。因此，如果U想要使用A，他必須在激活A之前停用B.
根據我在實施RBAC方面的經驗，我幾乎避免使用多會話的動態管理。起初，它聽起來像一個非常整潔和靈活的想法，但當你質疑誰激活/停用角色（以及何時）時，我意識到複雜性和安全性風險不值得這種努力（我個人認爲）。
重要的是要了解這裏和其@Imontriux（上文）中提到：
「這是有用的，例如，對於佔空比 約束動態分離，其中兩個角色A和B可以是分配給同一用戶 U，但不能一起使用，因此，如果U想要使用A，他必須在激活A之前使B去激活。
大多數情況下，必須採用職責分離的約束條件，爲了實現這個目標，我只選擇每次只有一個有效的會話/管理一個會話。如果用戶想要根據不同的角色進行身份驗證，則他/她負責註銷並重新登錄。
它大大簡化了我的許多代碼。這是我選擇的一種妥協方式，可以輕鬆生活。
在認證時間選擇和激活仍然是動態管理。該標準並沒有說它必須發生「蒼蠅」。至於安全性，它並不能阻止不好的事情發生，但它提供了一個很好的審計跟蹤，證明這個人知道有人犯了欺詐（例如）。我們有政府申請，公務員負責支付補貼，但也可以作爲公民登錄並申請補貼。這在技術上無法避免，也是你不想避免的。 – WanWizard
@WanWizard是的，我理解你的觀點。我所設想的是像Windows這樣的系統，你是一個普通用戶，當你嘗試執行一個特權命令時，它會彈出你的憑據來提升你的權限。顯然，Windows可能不會將一個會話與另一個會話進行交換，而是提供額外的權限。但這是我在'動態'中理解的。如果Windows要求您完全註銷，然後使用特權用戶重新登錄，對我來說這是不同的（即：靜態），而不是真正的動態管理。 – Jeach
我明白，從用戶友好的角度來看，你會想要這樣的東西。不過，從安全角度來看，Windows設計存在根本上的缺陷。它使用其他用戶的憑據來提升您的權限，從審計的角度來看，這是一場噩夢。而我的情況是沒有其他用戶，它是具有多個角色的同一用戶，並且由於職責分離，用戶可能沒有同時與這些角色關聯的權限。 – WanWizard
感謝橡皮擦，用戶如何選擇激活/停用角色？他什麼時候這樣做？考慮到用戶必須通過登錄表單進行身份驗證的簡單Web應用程序，用戶在提交登錄表單後是否選擇了角色？如果是的話，它是如何發生的？如果不成功，登錄成功後，創建會話時，該用戶如何激活/取消激活角色？ –
它取決於您正在使用的授權框架，以及如何在應用程序中實施訪問控制。例如，在Web應用程序中，訪問特定頁面可能會觸發某些角色的激活/停用。 RBAC標準在會話期間不會激活和取消激活角色，某些框架只會在登錄時激活所有角色。當然，在這種情況下，職責約束的動態分離是無用的。您可能想看看[RBAC標準]（http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf）。 – 2012-12-07 10:39:06
謝謝橡皮擦，我想我已經開始理解它了。從上面的鏈接可以看出，「在其他情況下，用戶可以根據用戶的意願選擇激活和停用給定會話中的角色」。這種網絡應用程序在哪裏使用？在我看來，它是你在答案中提到的管理Web應用程序。 –