Seam中基於ACL的許可權控制（1）

seam框架已經能夠解決大多數web程式開發中會遇到的問題。通過提供一系列基於「最佳實踐」總結出的統一模型，開發人員的web程式的開發工作變得非常輕鬆。程式設計師在開發具體的相關業務邏輯的時候，就不會再鬱悶了，因為大多數功能在seam中都有對應的模組來實現。例如，seam生成pdf、傳送email、實現國際化等，都非常方便。同時，seam還整合了許多第三方框架，例如drools、jbpm等，這些框架寫作能夠實現非常複雜的業務邏輯以及跨度時間很長的流程操作。其他還支援自動生成驗證碼、wiki風格的標記語言和一大堆ajax功能。

其中最重要的企業特性之一，就是seam的許可權控制部分。seam包含乙個非常健全的安全認證api，通過這個api，乙個典型的程式中需要用到的元件和檢視安全認證都能夠實現。seam通過使用者角色以及基於規則的許可權控制來實現安全控制。最近的版本中（2.1.0ga），seam重寫了安全引擎，提供了大量新的相關功能來保障敏感資料的安全。本文就來看看其中乙個新的特性——許可權的持久化，著重於介紹acl或者說是基於例項的安全機制是如何在物件級別保障你程式的安全的。

開始之前，讓我們先來看看基於規則的與基於acl的安全控制有什麼不同。基於規則的安全控制擅長於將一堆許可權授予某個物件。例如下面這段規則**（來自於seam的示例專案）：

drools**

rule deleteimage

no-loop

activation-group "permissions"

when

acct: memberaccount()

image: memberimage(mbr : member -> (mbr.memberid.equals(acct.member.memberid)))

check: permissioncheck(target == image, action == "delete", granted == false)

then

check.grant();

end

rule deleteimage no-loop activation-group "permissions" when acct: memberaccount() image: memberimage(mbr : member -> (mbr.memberid.equals(acct.member.memberid))) check: permissioncheck(target == image, action == "delete", granted == false) then check.grant(); end

這段規則做了這麼乙個限制：讓使用者有許可權刪除他之前上傳的。其中最重要的部分限制了，只有的所有者才能刪除。在這個例子中，該許可權加在所有上，並且在和其所有者之間擁有一種連線關係。通過這條關係，安全規則能夠決定當前使用者即為該的所有者，並且將相應的許可權授予其執行操作。不過，如果在需要檢查的物件的許可權如果與當前使用者沒有關聯呢？（在這裡，使用者就是只principal）這樣就需要acl了。

acl（訪問控制表）記錄了某個指定的物件與某個許可權之間的一一對應關係。每個記錄都擁有乙個接受者（被授予許可權的使用者principal）和乙個操作。如果你使用過unix系列的作業系統，那麼你就會對acl非常熟悉了，unix作業系統有乙個**用來記錄某個使用者對某個檔案的修改、刪除或執行許可權。當然windows也有這樣的機制，不過windows並沒有表現出他是這樣控制的。seam中的acl也是一樣的，唯一不同的就是，seam中acl記錄的物件是實體的例項，而不是檔案。通常情況下，這個物件為實體，不過我們將會看見，它可以應用到所有型別的物件上。

Seam中基於ACL的許可權控制（1）

ACL許可權控制

ACL許可權控制列表

ACL 許可權控制機制

Seam中基於ACL的許可權控制（1）

ACL許可權控制

ACL許可權控制列表

ACL 許可權控制機制

相關推薦