Partager via


將自訂宣告提供者中的 Secure Store Service 與 SharePoint 2010 搭配使用

最近在使用我正在處理的自訂宣告提供者中的 Secure Store Service (SSS) 時,我發覺一個絕妙的新構想。這實際上是一個很有趣的案例,因為我正在做許多人想要做的事:自訂宣告增強。我需要連線至遠端資料來源,以利查詢每個使用者的一些其他資訊,然後使用該資訊來判斷要增強或不增強哪個宣告。

在自訂宣告提供者中使用資料來源的一般指導方針中,請務必記住您的自訂宣告提供者組件將由 SharePoint STS 處理序保留在記憶體中。這使得擷取「資訊」變得容易許多 (方法是將資訊儲存在類別層級變數,然後在下一個 IISRESET 之前,它都是可供使用),不論該資訊是資料集、一組認證等等。此處最大的限制是,並非所有的 SharePoint 伺服器陣列資源在建立自訂宣告提供者類別時都可以使用,而這正是今日故事的寓意。

在這個特殊的案例中,我想要為我的自訂宣告提供者從建構函式的 SSS 中擷取資料,然後我要使用該資料來「做一些其他事情」;在我的例子中,我要從跨單向信任的網域來建立 WindowsIdentity,這樣我就可以使用它來建立具有查詢遠端 Active Directory 權限的模擬內容。不過會發生的問題是,當我嘗試使用建構函式中的 SSS 參照來執行任何作業時,它「一律」都會逾時。在 SSS 上呼叫哪種方法並不重要,它一律都會在 60 秒後失敗並產生逾時錯誤。

只要將程式碼移出建構函式即可修正此問題。從 FillClaimsForEntity 方法的覆寫中呼叫完全相同的程式碼時,執行得非常順利。在反覆試驗後能夠想出這個修正方式,真的非常幸運,因此似乎是值得分享的秘訣。

只要我們深入研究這個特殊問題 (登入遠端網域並模擬),就值得增加另一個我從此問題所獲得的另一個模式以及另一項發現。

如上方所述,因為您的組件會在 STS 處理序中保持載入狀態,所以可以將類別層級變數「保持運作」。因為我不想在需要查詢時重複登入遠端網域,所以我為 WindowsIdentity 建立類別層級變數。該模式會執行的作業如下:

  1. 查看我是否已擷取 SSS 認證
    1. 如果未擷取,會執行程式碼以進行下列作業:
      1. 從 SSS 擷取認證
      2. 使用 LogonUser API 透過我從 SSS 取得的認證登入遠端網域
      3. 建立 WindowsIdentity 變數,因此它有遠端使用者的認證
  2. 檢查 WindowsIdentity 變數是否為空白
    1. 如果未擷取,會執行程式碼以進行下列作業:
      1. 從 WindowsIdentity.Impersonate() 建立 WindowsImpersonationContext 的新執行個體
      2. 查詢遠端網域
      3. 在 WindowsImpersonationContext 呼叫 Undo

這個模式似乎運作良好,而且其效能也表現得很好。這裡有一項秘訣:您「不」要在 WindowsIdentity 執行個體上呼叫 Impersonate(),然後之後不要在產生的 WindowsImpersonationContext 上呼叫 Undo。如果您不要復原模擬,在我的經驗中,此網站將不會再顯示。請新增 Undo 回呼,這樣一切就會再重新運作。

這是翻譯後的部落格文章。英文原文請參閱 Using Secure Store Service in a Custom Claims Provider with SharePoint 2010