許可權控制可以看作一個filter模式的應用, 這也符合思想的應用條件。在一個簡化的圖象中，我們只需要將一個判別函式 isAllowed(subject, operation, resource)插入到所有安全敏感的函式呼叫之前就可以了。雖然概念上很完美，具體實現的時候仍然有一些細節上的問題。基本的困難在於很難在最細的粒度上指定許可權控制規則（連續的？動態的？可擴充套件的？），因而我們只能在一些關鍵處指定許可權規則，或者設定一些整體性的許可權策略，然後透過特定的推理來推匯出細粒度的許可權規則，這就引出結構的問題。我們需要能夠對許可權控制策略進行有效的描述（控制策略的結構），並且決定如何與程式結構相結合。subject, operation和resource為了支援推理，都可能需要分化出複雜的結構，而不再是簡單的原子性的概念。而在與程式結構結合這一方面，雖然使得我們可以擴充套件任何函式，但這種擴充套件需要依賴於cutpoint處所能得到的資訊，因而許可權控制的有效實施也非常依賴於功能函式本身良好的設計。有的時候因為需要對結構有過於明確的假定，許可權控制的實現不得不犧牲一定的通用性。

下面我們將分別討論一下operation, subject和resource的結構分解的問題。首先是operation。
說到推理結構，讓人最先想起的就是決策樹，樹形結構，在面嚮物件語言中可以對應於繼承。金字塔式的樹形結構也正是在現實世界中我們應用最多的控制結構。透過層層分解，operation的結構可以組織為一棵樹,
應用程式 ==> 各個子系統 ==> 每個子系統的功能模組 ==> 子功能模組
==> 每個模組的功能點(具有明確的業務含義) ==> 每個功能點對應的訪問函式(程式實現中的結構)
一個常見的需求是根據許可權配置決定系統選單樹的顯示，一般控制使用者只能看到自己有權操作的功能模組和功能按鈕。這種需求的解決方法是非常直接的。首先，在後臺建立子系統到功能模組，功能模組到功能點以及功能點到實現函式之間的對映表（如果程式組織具有嚴格規範，這甚至可以透過自動蒐集得到）。然後，在許可權配置時建立使用者與功能點之間的關聯。此時，透過一個檢視，我們就可以蒐集到使用者對哪些功能模組具有訪問許可權的資訊。

為了控制選單樹的顯示，witrix平臺中的SiteMap採用如下策略：
1. 如果使用者對某個子功能具有操作許可權，則所有父選單項都預設可用
2. 如果使用者對某個功能具有操作許可權，並且標記為cascade，則所有子選單項都自動預設可用
3. 如果明確指定功能不可用，則該選單及子選單都強制不可用
4. 如果明確指定功能對所有人可用，則不驗證許可權，所有子選單自動預設可用
4. 強制設定覆蓋預設值
5. 不可用的選單預設不可見
6. 明確標記為可見的選單即使不可用也可見
7. 父選單可見子選單才可見
我們透過預計算來綜合考慮這些相互影響的控制策略。儘量將推導運算預先完成也是解決效能問題的不二法門。

在witrix平臺中，每一次網路訪問的url都符合jsplet框架所要求的物件呼叫格式，需要指定objectName和objectEvent引數，這就對應於功能點的訪問函式。訪問控制點集中在objectManager並且訪問格式是標準的。使用等方式實現細粒度訪問控制，困難似乎在於不容易引入外部配置資訊（例如功能點資訊等），而且控制點所對應的物件函式格式也不統一，因而多數需要在細粒度上一一指定。

許可權系統設計(2)--operation

相關文章