在應用程式中，尤其是在統計的時候， 需要使用資料許可權來篩選資料行。 簡單的說，張三看張三部門的資料， 李四看李四部門的資料；或者員工只能看自己的資料， 經理可以看部門的資料。這個在微軟的文件中叫Row Level Security，字面翻譯叫行級資料安全，簡稱RLS。
要實現RLS， 簡單的思路就是加Where條件語句來做資料篩選。但是必須是先Where, 也就是在其他Where條件和OrderBy、Fetch Rows 之前執行， 否則會對 排序、分頁查詢造成影響。這是一個難點。
另一個難點是如何對現有的業務程式碼侵入性降到最低——不影響現有查詢邏輯的寫法，甚至當需要的時候，可以關閉RLS。為了校驗資料， 必須保持RLS開關的靈活性，尤其是在開發階段。
下面介紹我在專案中使用過的兩種實現方式。
資料許可權篩選（RLS）的實現（一） -- Security Policy方式實現
這個主要參考微軟的官文介紹實現， 分三個步驟， a. 定義Predicate函式, 根據user引數來篩選資料， b. 定義Security Policy, 使用前面指定的Predicate函式, c.在指定表上應用Security Policy。
其中的user, 一種是通過當前連線資料庫的登入使用者來獲取，一種是通過exec sp_set_session_context @key=N'userId', @value=@userId 來傳入使用者。後者更適合我們在應用查詢中使用統一的連線字串。由於我們資料訪問層是通過EF來實現的， 所以我們統一在自定義的DbContext型別中做了改造：
1 public abstract class RlsDbContext : DbContext
2 {
3
4 protected readonly IUserProvider userProvider;
5 protected RlsDbContext(
6 string connectionString,
7 IUserProvider userProvider)
8 : base(options)
9 {
10 this.connectionString = connectionString;
11 this.userProvider = userProvider;
12 }
13
14 protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
15 {
16 connection = new SqlConnection(connectionString);
17 if (enableRLS)
18 {
19 connection.StateChange += Connection_StateChange;
20 }
21
22 if (!enableMemoryDb)
23 {
24 optionsBuilder.UseSqlServer(connection);
25 }
26
27 base.OnConfiguring(optionsBuilder);
28 }
29
30 private void Connection_StateChange(object sender, System.Data.StateChangeEventArgs e)
31 {
32 if (e.CurrentState == ConnectionState.Open)
33 {
34 string userId = userProvider.CurrentUserId;
35 //此處判斷條件用於流程Hook介面未配置認證而獲取不到使用者的情況
36 if (!string.IsNullOrEmpty(userId))
37 {
38 SqlCommand cmd = connection.CreateCommand();
39 cmd.CommandText = @"exec sp_set_session_context @key=N'userId', @value=@userId";
40 cmd.Parameters.AddWithValue("@userId", userId);
41 cmd.ExecuteNonQuery();
42 }
43 }
44 else if (e.CurrentState == ConnectionState.Closed)
45 {
46 //暫時註釋：在分頁查詢場景下存在RLS獲取總數之前SQL連線關閉的情況
47 //connection.StateChange -= Connection_StateChange;
48 }
49 }
50
51 }
這樣， 我們就能確保在訪問資料庫的適合， 傳入了當前使用者資訊
具體的示例， 可以參考《Row-Level Security》
但是這個方式有個很大的問題， 就是效能不理想， 尤其是在判斷條件中有or邏輯的時候。 比如這個場景：每個部門只能看自己的資料，如果是資料管理員，不論在哪個部門， 可以看所有部門的資料。加了or邏輯後， 大概1w行資料查詢需要10s鍾，這超出了應用能接收的範圍。示例Predicate Function如下
1 CREATE FUNCTION [dbo].[Predicate_MyFilter_RLS]
2 (
3 @orgId nvarchar(200)
4 )
5 RETURNS TABLE
6 WITH SCHEMABINDING
7 AS
8 RETURN
9 SELECT TOP 1 1 AS AccessPredicateResult
10 FROM dbo.[User] a
11 WHERE
12 a.UserId = SESSION_CONTEXT(N'UserId')
13 AND
14 (
15 a.OrgId = @orgId OR a.OrgId = '0000000000000000000000'
16 )
17 GO
關於效能問題的佐證，可以參考《Row-Level Security for Middle-Tier Apps – Using Disjunctions in the Predicate》
由於效能問題的障礙， 所以我們放棄了這種實現方式。但是這種方式比較優雅的滿足了上述的兩個條件，即實現了底層資料先篩選的邏輯，也對業務查詢方法無侵入。在簡單的場景中，應該是一款適合的方案。
資料許可權篩選（RLS）的實現（二） -- 後臺RlsStrategy方式實現
另一種做法， 是我們自行研究的RlsStrategy的實現方式。首先我們瞭解下介面IRlsStragety
1 public interface IRlsStragety<TEntity, TUserConstraintEntity>
2 {
3 Expression<Func<TUserConstraintEntity, bool>> UserPredicate
4 {
5 get;
6 }
7
8 Expression<Func<TEntity, object>> OuterKeySelector
9 {
10 get;
11 }
12
13 Expression<Func<TUserConstraintEntity, object>> InnerKeySelector
14 {
15 get;
16 }
17
18 bool Skip();
19 }
這裡面提供了三個表示式和一個bool 方法判斷是否要略過RLS篩選。
下面是一個基本的實現：
1 public class GenericUserOrgRlsStragety<TEntity, TOrgUser> : IRlsStragety<TEntity, TOrgUser>
2 where TEntity : class, IUserId
3 where TOrgUser : class, IOrgUser
4 {
5 private readonly IOrgProvider userOrgProvider;
6 public GenericUserOrgRlsStragety(IOrgProvider userOrgProvider)
7 {
8 this.userOrgProvider = userOrgProvider;
9 }
10
11 public virtual Expression<Func<TOrgUser, bool>> UserPredicate
12 => user => user.OrgId == userOrgProvider.CurrentUserOrgId;
13
14 public virtual Expression<Func<TEntity, object>> OuterKeySelector
15 => entry => entry.UserId;
16
17 public virtual Expression<Func<TOrgUser, object>> InnerKeySelector
18 => user => user.UserId;
19
20 public virtual bool Skip()
21 {
22 return false;
23 }
24 }
下面我來解釋下這個邏輯。 假設應用中有這樣兩張表
T_BizData(Id, BizAmount, Org) 和T_OrgUser(Org, User), 前者是業務表， 記錄了業務資料和所屬業務組織的機構，後者是機構人員表，記錄了人員和機構之間的關係。 根據這兩個表，我們可以實現OrgA的使用者可以檢視OrgA的資料， OrgB的使用者可以檢視OrgB的資料
如果不考慮RLS， 則查詢語句是
Select * from T_BizData
如果考慮RLS， 則查詢語句是
Select a.* from T_BizData a
inner join T_OrgUser b on a.Org=b.org
where b.User=@user
兩者比較，我們發現多了一個限制表和三處靈活點：
1 限制表就是 inner join T_OrgUser b,
2 靈活點 a） 取左表屬性； b）取右表屬性； c）取右表條件判斷
這三個靈活點就是我們介面定義的三個表示式， 限制表是作為泛型型別傳入進來的。
理解了這一點， 我們就可以看看下面這個程式碼
1 public static IQueryable<TEntity> FilterByUser<TDbContext, TEntity, TUserConstraintEntity>(
2 this IQueryable<TEntity> queryable,
3 TDbContext dbContext,
4 IRlsStragety<TEntity, TUserConstraintEntity> rlsStragety
5 )
6 where TDbContext : DbContext
7 where TEntity : class
8 where TUserConstraintEntity : class, IUserId
9 {
10 if (dbContext is null)
11 {
12 throw new System.ArgumentNullException(nameof(dbContext));
13 }
14
15 if (rlsStragety == null
16 || rlsStragety.UserPredicate == null
17 || rlsStragety.OuterKeySelector == null
18 || rlsStragety.InnerKeySelector == null
19 || rlsStragety.Skip()
20 )
21 {
22 return queryable;
23 }
24
25
26 IQueryable<TEntity> result = queryable.Join(
27 dbContext.Set<TUserConstraintEntity>()
28 .Where(rlsStragety.UserPredicate)
29 , rlsStragety.OuterKeySelector
30 , rlsStragety.InnerKeySelector
31 , (p, q) => p
32 );
33 return result;
34 }
我們都知道queryable 是EF實現查詢的物件，它描述了查詢的過程，所以我們在原queryable物件的基礎上擴充了join邏輯， 從而實現了類似sql 語句的兩表inner join查詢。 該過程是在分頁之前加入的，這樣才能保證查詢的結果。
1 public virtual async Task<IPaged<TEntity>> GetPagedListAsync<TEntity>(object filter, CancellationToken cancellationToken = default) where TEntity : class
2 {
3 if (filter == null)
4 {
5 filter = new object();
6 }
7 IPaged<TEntity> result = new Paged<TEntity>();
8
9 IQueryable<TEntity> queryable = GetPagedQueryable<TEntity>(filter);
10 result.Rows = await queryable.ToListAsync(cancellationToken).ConfigureAwait(false);
11
12 IQueryable<TEntity> queryableForCount = GetCountQueryable<TEntity>(filter);
13 result.Total = await queryableForCount.CountAsync(cancellationToken).ConfigureAwait(false);
14
15 return result;
16 }
以上準備工作做好了， 在查詢的時候，就可以這樣寫了：
stragety =
serviceProvider.GetService<MyRlsStragety>(); var pageList = await rlsDataInquirer.GetPagedListAsync(filter, stragety);
最後， 補充下skip()方法的邏輯。
public override bool Skip()
{
string orgId = userOrgProvider.CurrentUserOrgId; // 如果是資訊管理部則跳過關聯判斷
return orgId.Equals(InfoSupervisorDepartmentOrgId, StringComparison.CurrentCultureIgnoreCase);
}
我們看到，FilterByUser方法的第19行， 如果skip()返回為true， 則會跳過RLS的邏輯。這個主要是為了特殊處理高階管理許可權設計的。
總結：
使用Security Policy 除了可以過濾使用者許可權資料外， 還可以用於更新和刪除資料時的許可權檢查； 而使用RlsStrategy則只能基於現有的框架來實現查詢資料行時的篩選，但是效能上要好很多，而且也比較靈活。同時，因為底層是轉換成了SQL語句，所以對欄位加索引應該可以進一步提高查詢的效能。