2009-12-14 180 views
4

我們目前有一個非常簡單的安全模式過濾器的數據...策略,根據用戶訪問級別

我們的資源,也大致映射到表中,我們可以訪問該資源(添加,修改,刪除,查詢),我們有組。

每個權限由資源,具有指定的訪問和一羣

並且每個用戶都可以屬於多個組...

因此,許可是多到多組之間,接入和資源

,我們也有一個多到許多用戶和組之間。

這只是罰款,我們的需要......

什麼,我試圖想是授予權限的數據,在創紀錄的水平,具有類似方案的方法。我需要一種根據用戶訪問級別「過濾」記錄的方法。

例如,屬於某個羣組的用戶可以看到表(資源)的所有記錄,但來自另一個羣組的用戶只能看到滿足特定條件的記錄,他們看到過濾的數據...

我在想增加一個「表情」字段權限表,以便訪問某個資源應用過濾器(實際上,當那將是一個有點複雜,我將不得不申請組的每個過濾器到該用戶所屬,加入了與一個「或」)

我想它是作爲一般的和可配置儘可能...

你會如何處理這樣的情況下使用?

+0

您使用的數據庫是? – 2009-12-14 17:34:18

+0

M $的SQL Server ...我們有一個觀點來解讀的許多一對多一對多的關係,爲我們提供了資源和訪問列表給定用戶... ,我們提出的是動態的每個查詢,這就是爲什麼我在想添加表情... – opensas 2009-12-14 17:36:50

回答

1

我看你已經沒有解答 - 我當然不知道的正確答案是什麼你,但這裏是我的觀點爲它的價值。

我可能誤會了,但如果我試圖強制執行角色/組細粒度的訪問控制的資源,我會做它在應用程序而不是在數據存儲解決方案。

我不知道這是在這種情況下,你的一個選擇,但如果你做的是,在數據層的安全性,你可能會遇到下一個缺乏彈性,甚至供應商鎖定的線路問題如果你最終使用專有擴展。

任何支撐/衝突的觀點在這裏非常感興趣。

+0

這聽起來很合乎邏輯確實,但我們在大部分經營業務邏輯的分貝水平執行,使用存儲過程......我們的SP只接收XML,解析和框架相應的行動,我們的應用程序只是建立這些XML,讓數據庫驗證一切... – opensas 2009-12-14 20:10:06

+1

哇 - 有趣的約束,你到了那裏!祝你好運...! – Brabster 2009-12-14 21:46:08

1

您對使用「表達式」過濾器和動態創建的SQL語句(右?)來過濾數據應該工作的想法。唯一的其他真正的選擇似乎需要一個固定的一組過濾器的「軸」上可以定義用戶訪問記錄。在兩種基本機制之間做出決定需要更多關於應用程序的細節。作爲一個(明顯),例如,在我的僱主的應用程序的每個客戶端(記錄)被分配給一個「辦公室」,我們提供了控制哪些用戶可以訪問用戶在辦公室的安全機制。這是使用我描述的第二種機制實現的,因爲它對我們的應用程序設計非常重要。如果你正在構建更多的是「元應用程序」,你可能希望實現一個更通用的解決方案,使您可以更容易地更改此行爲。

1

我會強烈建議尋找到一個ORM(對象關係映射)框架,它具有動態地構造查詢的能力。基本思想是你可以根據已登錄用戶的安全性在應用程序代碼中構造標準,並且該框架將其轉換爲在服務器上執行的SQL(因此,您不會將所有記錄都拉入應用程序層並在那裏過濾)。這種方法與使用直接動態SQL的區別在於,ORM將允許您編寫類型安全的代碼,其中直接動態SQL是基於字符串的,這使得它容易出現人爲錯誤。

一些ORM框架都帶有授權功能開箱即用,這可能(或可能不是)比上述我不同,但也可以把工作做好。

我知道肯定LLBLGEN Pro有一個非常強大的動態查詢引擎,並支持行級授權。我不是NHibernate或Entity Framework的專家,但我確信他們也有這種支持。

即使你不打算使用的持久性的ORM(其主要用途),它可能仍然是值得給他們看看他們的動態查詢功能。

1

我們擁有的AccessControlEntry表看起來像這樣:

CREATE TABLE [dbo].[AccessControlEntry] 
(
    [subjectId] [nvarchar](256) NOT NULL, 
    [objectType] [varchar](256) NOT NULL, 
    [objectId] [int] NOT NULL, 
    [permission] [varchar](50) NOT NULL, 
    [flag] [int] NOT NULL DEFAULT (0), 
    [applyToChildren] [int] NOT NULL DEFAULT (1), 
    CONSTRAINT [PK_AccessControlEntry] PRIMARY KEY CLUSTERED ([subjectId] ASC, [objectType] ASC, [objectId] ASC, [permission] ASC) 
) 

我們正在設置權限的用戶ID是subjectId,對象類型和對象ID識別我們設置上(在資源許可的對象你術語)。在我們的例子中,我們爲每個權限(即列表,查看,創建,修改,刪除)提供單獨的記錄 - 但是您可以輕鬆地爲每個權限設置一個列。

然後,我們創建了接受subjectId,的objectType和任選的的ObjectID,並返回權限的表值函數。

一旦你的,你最終與此表值函數顯示幾乎所有的疑問的,所以你可以過濾什麼獲取用戶對資源的權限返回。

由於我們的數據是(在公司有點像業務部門)層次的性質我們的許可系統處理權限和繼承的層次結構。我對你的數據模型並不熟悉,所以我不知道你有這樣的要求 - 但這個想法與你如何對目錄和文件應用安全權限類似。

+0

看起來像這樣會讓這個AccessControlEntry在擁有中等數量的用戶(1,000,000)時變得非常龐大。如果您有十萬個不同的對象,這意味着您的表中可以有10^11個條目。這是巨大的, – 2015-02-17 13:41:44