4
我正在研究一個具有CRM功能的大型Java EE web應用程序，我們正在尋找一種安全方法/庫/解決方案/任何東西。基本的基於角色的安全性不起作用，因爲訪問控制必須基於角色和的層次結構，但必須可選地針對每個文檔進行定製。由於將存儲保密和專有信息，因此要求安全性正常工作。如何管理大量的權限？
舉例：要使用百貨商店，貨架潛行者儲料機可以創建報告，其他儲料機可以讀取只有他們是在同一個部門。現在，他們的部門經理可以讀/寫/更新/刪除所有由存貨人撰寫的報告，並撰寫所有其他部門經理可以閱讀的報告，但不能查看區域經理可以使用的商店經理等的報告。複雜性：高層人員可以讓低層人員看到事物，或者向個人（部門向多個特定存儲員寫文檔）或其下的每個人（店鋪經理向整個商店寫備忘錄）或任何你可以想象的排列。此外，個人可以創建他們的同事看不到的報告，或者他們可以選擇授予訪問權限來存儲其他地區的存儲器等。
我們正在考慮一個ACL，每個實體只有一個權限，但擔心大量記錄會創建。即使只有一個30歲以上的部門的每個人都可以讀懂報告（在指揮系統中），那麼創建單個報告需要〜40條記錄！每個用戶每週有1個報告，每個用戶每年有2000個權限。 1,500個用戶意味着每年超過3,000,000個權限。
這似乎是一個規則引擎爲基礎的方法將是很好的，但所以我們不敢隨便說的方法，我還沒有看到任何博客或文章提的是方法。
我們也在考慮一些ACL /規則的自制混合，您可以授予一個部門ID與「經理」或「股東」等鑑別器的權限，但擔心檢查所有可能的權限你可以專門由其他用戶授予權限，你有權爲你的部門的memeber，你可以有權限的商店，或區）的成員聽起來像一個容易出錯的繁瑣的噩夢。
我們的應用程序的最佳方法是什麼？
春天ACL絕對是一個考慮因素。但是，我們希望分發應用程序，我們知道，我們必須在後端服務器上爲每次調用它們創建一個新的安全上下文。我們不希望在前端安全，以便我們可以重複使用其他前端（可能是iPad應用）的安全性。這看起來很醜陋，不可取，但絕對可行。 – ArtB 2011-04-21 16:20:32