canonical

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

   下面我們將分別討論一下operation, subject和resource的結構分解的問題。首先是operation。
    說到推理結構，讓人最先想起的就是決策樹，樹形結構，在面向對象語言中可以對應于繼承。金字塔式的樹形結構也正是在現(xiàn)實世界中我們應用最多的控制結構。通過層層分解，operation的結構可以組織為一棵樹,
   應用程序 ==> 各個子系統(tǒng) ==> 每個子系統(tǒng)的功能模塊 ==> 子功能模塊
      ==> 每個模塊的功能點(具有明確的業(yè)務含義) ==> 每個功能點對應的訪問函數(shù)(程序實現(xiàn)中的結構)
   一個常見的需求是根據(jù)權限配置決定系統(tǒng)菜單樹的顯示，一般控制用戶只能看到自己有權操作的功能模塊和功能按鈕。這種需求的解決方法是非常直接的。首先，在 后臺建立子系統(tǒng)到功能模塊，功能模塊到功能點以及功能點到實現(xiàn)函數(shù)之間的映射表（如果程序組織具有嚴格規(guī)范，這甚至可以通過自動搜集得到）。然后，在權限 配置時建立用戶與功能點之間的關聯(lián)。此時，通過一個視圖，我們就可以搜集到用戶對哪些功能模塊具有訪問權限的信息。

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

  在witrix平臺中，每一次網(wǎng)絡訪問的url都符合jsplet框架所要求的對象調用格式，需要指定objectName和objectEvent參 數(shù)，這就對應于功能點的訪問函數(shù)。訪問控制點集中在objectManager并且訪問格式是標準的。使用spring等AOP方式實現(xiàn)細粒度訪問控制， 困難似乎在于不容易引入外部配置信息（例如功能點信息等），而且控制點所對應的對象函數(shù)格式也不統(tǒng)一，因而多數(shù)需要在細粒度上一一指定。