共用方式為

  • 發行項

本文章是由機器翻譯。

SharePoint 安全性

在 SharePoint 2010 自訂宣告型安全性

富裕的 Feng[

佛節 Stanko](https://msdn.microsoft.com/zh-tw/ee532098.aspx?sdmr=patrickstanko%26sdmi=authors)
Shabbir Darugar

下載程式碼範例

Microsoft SharePoint 2010 引進了新的宣告式身分模型，建置宣告感知應用程式。宣告感知應用程式給使用者時，她會提供一組宣告為應用程式的識別。這些宣告會讓內容更細微的授權。因此，使用者有特定的屬性，例如國家 (地區) 的程式碼 」 和 「 部門代碼，會授與適當的內容的存取權。

實作企業層級的宣告式安全性提供一些有趣的挑戰。我們將探討建置在 SharePoint 中的自訂宣告提供者 (CCP)、 將這與 Microsoft FAST Search Server 2010 for SharePoint 整合、 從使用者的觀點來看，管理已啟用宣告的內容及避免某些因素的程序。當我們這麼做時，您將學習如何設計及實作動態自訂的宣告式安全性模型在 SharePoint 2010。我們將使用 Contoso 公司的人力資源入口網站、 ContentWeb，我們的範例。

應用程式的概觀

Contoso 已接近到 100000 名員工使用的跨國企業，而且 ContentWeb 會保存許多內容作者需要管理上為每週的每日的資訊。在大部分的情況下，內容是適用於一個國家 (地區) 的小組成員，但不可為另一個，以一個專業領域，但不可為另一個，或以 [康得股份有限公司的所有員工。部份內容，不過，就必須能讓員工 (如 VPs) 一小部分的機密資料。

若要涵蓋廣大的群眾，ContentWeb 會使用 SharePoint 群組 (SPGs)，以自訂宣告明確安全，並為目標的內容。特定的宣告，contoso 公司的需求是儲存在資料庫中，用來定義使用者的宣告 」 集合。"它是這組宣告，決定某位員工的可以和看不見。系統管理介面可讓資訊工作者所支援的入口網站的變更，或是強化其本身的宣告集合，讓它們能夠檢視不同的使用者身份的 「 入口 」。這個功能強大的自訂功能就稱為檢視入口網站為 (VPA)。

在 SharePoint 2010 和快速搜尋伺服器 2010年宣告式 Windows 驗證用於 SharePoint、 搜尋引擎聯盟的企業搜尋環境中為 ContentWeb。

CCP 為何？

使用者何時登入 ContentWeb，「 宣告式 Windows 驗證 」 提供一組可做為識別提供者的 Active Directory 中宣告。不過，單靠這些聲明並不是足夠的安全，並為目標內容的 ContentWeb 的。ContentWeb 需要額外的使用者資訊，例如 SAP 建置描述使用者完整的宣告集合的企業資料儲存機制中。因此，我們需要 CCP 來擴大的宣告。我們使用這些自訂宣告明確安全目標使用者的內容。

CCP 讓康得股份有限公司判斷什麼宣告型別和其值為想来用來描述員工、 廠商和其他人使用，其效果。這種模型是可擴充的。 它可以讓 [康得股份有限公司逐個變更時而隨其商務變更。

因為您不能輕易地編輯來自 [Active Directory 的宣告，您也需要支援 VPA 的 CCP。只有經過授權的人員 (使用者 A) 想要檢視與另一個人 (使用者 B) 的 「 入口 」 時，主要使用 VPA。在這種情況下，自訂宣告的提供者將 b 使用者的自訂宣告加入使用者 a 的宣告集合，因此授權使用者檢視 b 使用者可以存取的內容。

使用者擁有的宣告是屬性，表示他 「 設定檔 」。使用者可擁有簡單及複合的宣告。簡單的宣告，例如國碼和 UserType，皆可輕鬆地了解。ContentWeb 會使用一組預先定義的簡單宣告 — 或者，更準確的說，簡單的宣告類型。不過，有時候某位員工必須授與權限內容，有一個以上的宣告型別 ； 比方說，國碼 = 我們和 UserType = FullTimeEmployee — AND 條件。在此情況下，您可以建立複合的宣告。

方塊中，用完 SharePoint 2010 評估使用 OR 邏輯只設定使用者的宣告中宣告。這表示 SharePoint 2010 支援僅 OR 條件的安全性，並為目標，而且這不一定適足夠。讓我們來看一個範例。ContentWeb 同時有國碼宣告和 UserType 宣告。需要安全全職的美國的某些內容使用國碼員工 = 我們和 UserType = FullTimeEmployee。我們無法滿足這個需求，直接在 SharePoint 2010 使用國碼或 UserType，簡單的宣告，因此我們必須在建立複合的宣告，以表示使用這兩個宣告中。

我們可以建立新的宣告型別為全職的美國員工。不過，如果公司在其他國家/地區，建立新辦公室，我們則需要更新我們的 CCP 來源程式碼，才能新增對應的宣告型別。很明顯地，這種方法可以是成本較高並且費時。此外，ContentWeb 業務小組想要能夠新增和移除複合的宣告類型，而不需要新的應用程式版本每次。如您所見，ContentWeb 就會需要動感，也可延伸的安全性模型。

我們如何將管理的所有宣告資料？我們將使用一個稱為 ContentWebAdminDB 的資料庫來儲存宣告的中繼資料。ContentWebAdminDB 是宣告來源端。 它會將合併 SAP 和其他企業資料庫中的所有宣告來源資料。我們將深入探討此資料庫的位元中的多。然後，我們將使用一般的 ASP。NET 應用程式的系統管理呼叫 ContentWebAdmin 來建立及更新複合宣告的中繼資料和 VPA 組態資料。(這個應用程式的詳細資料是超出本文的範圍)。複合的宣告會建立使用簡單的宣告。例如，ContentWebAdmin 應用程式中我們可以建立複合宣告稱為使用國碼美國 FullTimeEmployee = 美國及 UserType = FullTimeEmployee 簡單的宣告。含有此 coumpound 宣告中繼資料中，任何使用者都有國碼 = 美國及 UserType = FullTimeEmployee 簡單的宣告，新的複合宣告美國 FullTimeEmployee = true 將會加入到使用者的宣告集合。集中營附近沒有宣告美國 FullTimeEmployee 的附註 = 會出現在任何使用者的宣告集合。這種動態的複合宣告設計，每一位使用者雖只有少數的數十個宣告在總計中的複合宣告排列可能會非常高。這是要確保最佳效能的索引鍵。

當使用者登入 ContentWeb 時，CCP 會叫用。CCP 會呼叫自訂預存程序，sp_GetUserClaims，ContentWebAdminDB，同時傳入使用者的身分識別宣告中。預存程序會檢查 VPA 設定，並傳回 CCP 所有簡單及複合該使用者的宣告。如您所見，動態複合聲明並不是動態的授權規則相同。我們的解決方案並不會變更的方式 SharePoint 2010 的複合主張評估宣告。我們只需要插入複合宣告的中繼資料設定為基礎的使用者宣告集合複合的宣告。[圖 1 會顯示 ContentWeb 的高階概觀。

圖 1 的 ContentWeb 的高階檢視

ContentWeb 自訂宣告的提供者內

ContentWeb CCP 具有特殊的類別繼承自 Microsoft.SharePoint.Administration.SPClaimProvider。[圖 2 顯示這個類別的一部分。請注意 16 一行程式碼 (其中的 [顯示文字] 屬性設定)。我們會新增它，讓我們的自訂宣告型別和值顯示更易於使用且可讀取的方式。

[圖 2 進行宣告一目瞭然

protected override void FillResolve(
  Uri context, string[] entityTypes, SPClaim resolveInput,
  List<Microsoft.SharePoint.WebControls.PickerEntity> resolved)
{
  string claimTypeName = string.Empty;
  string claimValue = string.Empty;
 
  // Handles only ContentWeb claim types
  if (null != resolveInput && resolveInput.ClaimType.Contains(
    ContentWebClaimTypes.ContentWebClaimTypePrefix))
  {
    claimValue = resolveInput.Value.ToLower();
    claimTypeName = GetName(resolveInput.ClaimType);
 
    PickerEntity entity = CreatePickerEntity();
    entity.Claim = resolveInput;
    entity.Description = resolveInput.ClaimType + " = " + claimValue;
    entity.DisplayText = claimTypeName + " = " + claimValue;
    entity.EntityData[PeopleEditorEntityDataKeys.DisplayName] =
      claimTypeName + " = " + claimValue;
    entity.EntityType = SPClaimEntityTypes.User;
    entity.IsResolved = true;
    resolved.Add(entity);
  }
}

ContentWeb CCP 需要在 ContentWebAdminDB 中的預存程序尋求使用者宣告的連接字串。 CCP 是陣列層級的功能，因為它不是範圍內的任何 Web 應用程式中，所以我們不能使用 web.config 檔來設定資料庫連接字串。 我們可以使用在 machine.config 中，但這不是理想因為我們有多個 Web 的前端。 相反地，我們將使用 SharePoint 階層式物件存放區，SPPersistedObject，來儲存資料庫連接字串。 這會存放在 SharePoint 設定資料庫，讓資料庫連接字串至所有的 Web 前端 SharePoint 伺服器陣列中。

內部 ContentWeb CCP，我們建立的類別繼承自 Microsoft.SharePoint.Administration.SPPersistedObject，如所示圖 3。

[圖 3 ConnectionStringStorage 類別

[Guid("56705e15-abd3-44f0-adea-91488da1a572")]
public class ConnectionStringStorage
  : Microsoft.SharePoint.Administration.SPPersistedObject
{
    [Persisted]
    private string m_connectionString;
 
    public ConnectionStringStorage()
    {
    }
 
    public ConnectionStringStorage(
      string name, SPPersistedObject parent)
      : base(name, parent)
    {
    }
 
    public ConnectionStringStorage(
      string name, SPPersistedObject parent, Guid guid)
      : base(name, parent, guid)
    {
    }
 
    public string ConnectionString
    {
      get { return m_connectionString; }
      set { m_connectionString = value; }
    }
}

若要註冊的資料庫連接字串，我們將使用下列的 Windows PowerShell 指令碼：

[System.Reflection.Assembly]::LoadWithPartialName(
  "Microsoft.Sample.ContentWeb.ClaimsSecurity")
$id = new-object System.Guid("56705e15-abd3-44f0-adea-91488da1a572")
$farm = Get-SPFarm
$existingObject = $farm.GetObject($id)
$existingObject.Delete()
$newObject =
  new-object Microsoft.Sample.Contoso.ClaimsSecurity.ConnectionStringStorage(
  "ConnectionString", $farm, $id)
$newObject.ConnectionString = "Data Source=ContentWebAdminSQLServer;
  Initial Catalog=ContentWebAdminDB;Integrated Security=True;Timeout=30"
$newObject.Update();
Iisreset

如您所見，我們會參考 CCP dll。 我們會建立新的 ConnectionStringStorage 物件，並將其連接字串] 屬性設定。 最後，我們稱它的 Update 方法，來將其儲存到 SharePoint 設定資料庫。

建議的連接字串逾時值小於 60 秒。 CCP 有 60 秒的執行預設的逾時。 這表示如果資料庫連接逾時，您必須能夠擷取連接字串，而不是一個容易讓人誤解 CCP 執行真正例外狀況。

內部 CCP 的建構函式，我們會擷取連接字串，並將它儲存在模組層次變數：

public class ContentWebClaimProvider : SPClaimProvider
{
  private static string connectionString = null;
 
  public ContentWebClaimProvider(string displayName)
    : base(displayName)
  {
    Guid guid = new Guid(@"56705e15-abd3-44f0-adea-91488da1a572");
    ConnectionStringStorage storage =
      (ConnectionStringStorage)SPFarm.Local.GetObject(guid);
    connectionString = storage.ConnectionString;
  }
}

我們想要能夠追蹤當 CCP 連接至資料庫中的使用者的宣告。 SharePoint 2010 有非常適合這樣的新功能。 看看有哪些 Microsoft.SharePoint.Utilities.SPMonitoredScope 物件，它會監視效能，並指定程式碼區塊的資源使用。 下列程式碼會記錄 CCP 資料庫呼叫：

using (new SPMonitoredScope("ContentWeb.CCP.GetUserClaims", 5))
{
  userClaimsDataSet = CustomClaimSourceDA.GetUserClaims(
    userAlias, connectionString);
}

我們也可以在 SharePoint 管理中心] 中設定的事件層級與這個事件的追蹤層級。這些受監視物件，在 SharePoint 基礎類別，在 [監視] 下 |報告 |設定診斷記錄。

ContentWebAdminDB 資料庫內

ContentWebAdminDB 如先前所述，將從 SAP 和其他企業資料庫中，使用者的宣告資料彙總，並且包含自訂宣告的來源。ContentWeb CCP 呼叫預存程序 sp_GetUserClaims，以擷取使用者的自訂宣告。

ContentWebAdmin 應用程式可讓授權的使用者，若要設定使用者的複合的宣告和 VPA。ContentWebAdminDB 會將複合宣告設定中繼資料和 VPA 的設定儲存在資料表中。和當 ContentWeb CCP 呼叫 sp_GetUserClaims 時，此預存程序會檢查 VPA 組態退件而簡單的宣告和複合的宣告。詳細的設計與實作此資料庫已超出本文範圍。不過，我們會包含可下載的程式碼封裝內的硬式編碼的宣告值以虛設的 sp_GetUserClaims，預存程序的 SQL 指令碼。

使用 SharePoint 群組

SPG 是 SharePoint 使用者中的邏輯包裝函式。這是很方便的 ContentWeb，使用數百個複合的宣告。如果沒有 SPGs，也很難管理的所有宣告內容的作者。

使用 SPGs 有下列好處：

  • 好記的命名： SPGs 可讓使用者在建立好記且有意義的群組名稱的潛在著這神秘的宣告值。例如，ContentWeb 有 SPG 名為"我們全職員工 」，描述所宣告的使用者國家 (地區) 的值 = 美國 CompanyCode = 1010年並 UserSubType = 項目。
  • 支援人員選擇器名稱解析： SPGs 的人員選擇器控制項，在 SharePoint 2010 原生支援的名稱解析。因此很容易尋找並選取 SPGs，如所示圖 4。

[圖 4 SharePoint 群組中的人員選擇器

  • 動態宣告安全性管理： 假設您需要變更的 「 我們全職員工 」 新增 UserType 定義其他屬性 = Corp — 國家 (地區) = 美國 CompanyCode = 1010年和 UserSubType = 項目 — 受限於變更商務需要。很容易就能在只是該一 SPG，並受到保護，因為 SPG 就會自動繼承此變更的所有物件進行變更。
  • 保障與目標內容只是一個 SPG： SharePoint 2010 現在能支援安全，以及使用相同的 SPG 的物件為目標的能力。這減少一般與建立對象，匯入的使用者設定檔中，執行設定檔同步處理工作，這樣的權利，為目標。
  • 多個宣告關聯一個 SPG： 讓我們假設您需要的層級範圍是從 60 至 65 的全職員工的保全網頁。容易您可以藉由建立具有 UserSubType 的 compund 宣告 SPG = 項目，並 Level = 60，UserSubType = 項目，並 Level = 61…UserSubType = 項目，並 Level = 65。SharePoint 2010 會解譯為這些宣告的所有"OR"。

管理許多的 SPGs 就可能會耗費時間、 很麻煩且容易產生錯誤。ContentWeb 的業務小組會使用 Excel 檔案，來管理數以百計的群組有關聯的自訂宣告。

沒有自動化的 SPGs 建立的各種選項。我們建立一個 XML 檔案來自動化此作業會讀取資料的 Windows PowerShell 指令碼。(您會發現這段指令碼中的程式碼下載，您可以從下載 code.msdn.microsoft.com/mag201111SPSecurity。)我們產生使用業務小組的 Excel 檔案的 XML 資料檔案。[圖 5 會顯示範例的 XML 組態檔。

[圖 5 XML 組態檔範例

<?xml version="1.0" encoding="utf-8"?>
<SharePointGroups url="http://contentweb" owner="contoso\ivfeng" >
  <SharePointGroup name="ContentWeb-FTE"
    description="ContentWeb-FTE" permissionLevel="Read">
    <Claim type="UserType" value="emp"/>
  </SharePointGroup>
  <SharePointGroup name="ContentWeb_US_0000_Emp_Corp_HRPro"
    description="ContentWeb_US_0000_Emp_Corp_HRPro">
    <Claim type="CompoundClaim" value="US+emp+corp+hrpro"/>
  </SharePointGroup>
  <SharePointGroup name="ContentWeb_US_0000_Emp_Corp_Manager"
     description="ContentWeb_US_0000_Emp_Corp_Manager">
    <Claim type="CompoundClaim" value="us+emp+corp+manager"/>
    <Claim type="CompoundClaim" value="US+emp+corp+hrpro"/>
  </SharePointGroup>
</SharePointGroups>

使用 SPGs 設為目標

若要使用為目標，您必須啟用 Web 應用程式的使用者設定檔服務應用程式。

沒有一個微妙的問題，要注意的目標上使用 SPGs。我們一開始會找到包含 Active Directory 使用者或安全性群組 [細緻]、 所使用的所有 SPGs，但包含自訂宣告使用者 SPGs 無法完全運作。根本原因被關係到這些群組的使用權限等級。當我們建立的自訂宣告的 SPGs 時，我們不想要指派任何預設權限層級。不過，如果 SPG 未指派使用權限等級建立，並在稍後用於安全性時，它仍會標示出來與特殊權限等級稱為 「 限制的存取，如所示圖 6。

圖 6 SharePoint 群組具有存取限制

因為 ContentWeb 有數百個 SPGs，而且其中大部分僅適用於使用主要的讀者，它們不需要設定任何權限層級。不過，目標觀眾處理器無法提取這些 SPGs，而不需任何的使用權限等級。我們幸運，而且發現因應措施，透過 [我們已將套用至的目標對象] 頁面的權限 UI。我們授與 「 讀取 」 權限所使用的目標對象，然後立即 SPGs 復原這項使用權限。此程序會導致 SharePoint 以有限的存取權限等級下，這些 SPGs 的旗標，目標觀眾願意接受該權限層級。請務必注意您不需要檢查這種授與，如 SPGs 多次復原程序。您需要執行此項作業就可以一次安全性繼承樹狀結構中。請注意如果您中斷安全性繼承時，您需要一次，即使您已經完成了父層級。

實作 ContentWeb 的搜尋

我們與這個應用程式的主要目標之一，就是改善 contoso 公司的員工的搜尋經驗。我們希望讓內容的 ContentWeb 得更容易找到比原本在過去。

若要執行這項操作的 ContentWeb，我們可以使用 [快速搜尋伺服器 2010 sharepoint 裝載在同盟環境中。請參閱上一步圖 1 ，contoso 公司的聯盟快速搜尋環境。以下範例顯示稱為快速搜尋同盟陣列的 SharePoint 伺服器陣列。這塊田地背後是 Microsoft 快速搜尋伺服器 SharePoint 引擎及資料庫。快速搜尋] 伺服器陣列中包含所有查詢搜尋服務應用程式 (查詢 SSAs) 和內容為 ssa 之。

當然，我們會建立內容內現存的內容為 ssa 之來源。(快速搜尋伺服器建議您只有一個內容為 ssa 之)。完成之後，內容為 ssa 之將耙梳 ContentWeb 的內容資料庫，並讓 ContentWeb 及其他內部網路應用程式可以使用搜尋索引。

然後，我們會建立個別的查詢為 ssa 之，它發行至 ContentWeb。與初始的搜尋在 ContentWeb 上測試，我們發現基本搜尋有效，但搜尋安全性調整根本無法運作，如預期般運作。受到保護的 ContentWeb 自訂宣告的任何頁面，使用者可能無法看到搜尋結果中的連結即使它們具有安全性權限。我們最後想到我們需要有登錄搜尋安全性調整運作的快速搜尋 SharePoint 伺服器陣列中的自訂宣告的型別對應的 ContentWeb。快速搜尋 SharePoint 伺服器陣列部署 CCP 是簡單的方法。不只我們必須確認註冊對應的宣告類型，我們也必須確定所有宣告 Id (顯示為帳戶在圖 7) 是相同的宣告型別值組的所有 SharePoint 伺服器陣列之間選擇。

[圖 7 宣告 Id

目前，即使有了 SharePoint 2010 年 6 月 2011年累積的更新，宣稱是不變的 SharePoint 2010 中的型別對應。CCP 是部署在 SharePoint 2010 陣列中，宣告的型別對應登錄，並維持不變的即使您移除並重新部署 CCP。因為您可能會對多個 SharePoint 農田 CCPs，也非常重要的您必須部署所有 CCPs 以相同的順序，以確保宣告 Id 都是相同所有的陣列。如果您不要這麼做，將不會對齊順序識別碼左邊，搜尋將傳回精確的結果。

當 ContentWeb 內容遭到耙梳時，CCP 是不會叫用。所需的所有已註冊在陣列中的快速搜尋]，以便耙梳工具引擎可以解碼 ContentWeb 自訂宣告的宣告型別對應。然後會在搜尋索引中儲存已解碼的自訂宣告的安全性。移除 ContentWeb CCP 是選擇性的因為會保留宣告的型別對應。此外，我們不需要 ContentWeb CCP，加強使用者在 [快速搜尋] 伺服器陣列的宣告。

安全性調整搜尋結果： Contoso 公司的內部網路入口網站

為了要從其他 contoso 公司的內部網路入口網站，您可搜尋的 ContentWeb 內容，您必須確定下列項目：

  • 要呈現的 ContentWeb 內容的所有內部網路入口網站必須在 SharePoint 2010 上建置，而且是宣告式 Web 應用程式使用 Windows 驗證。
  • 所有的內部網路入口網站必須查詢相同的快速搜尋索引。
  • 所有的內部網路入口網站都必須有 ContentWeb CCP 安裝。(如果有一個以上的 CCP，它們都必須安裝在相同的順序，以確保的宣告 Id 皆。)

如果所有這些條件都符合，ContentWeb 的內容會可搜尋所有 contoso 公司的內部網路入口網站。

完成

SharePoint 2010 提供強式的整合，以宣告式安全性。SharePoint 群組、 宣告和自訂宣告的提供者，可讓您授權廣泛細微層級和企業的內容。如您所見，您就可以輕鬆滿足許多案例。

這種設計也可讓開發人員建置以改變其宣告和檢視站台，以不同的使用者，然後還原可以讓資訊工作者 (例如，支援人員) 的強大工具。

就如同大部分新的設計實作，我們的經驗並沒有"的機會來了解，"不是，但在最終產品是很值得。我們提供的範例程式碼應該可以幫助讓您正確的方向，以及關好的開始部署您的下一步 gen 企業入口網站!

Jinhui (Ivory) Feng 是資深軟體開發工程師在 Microsoft 處理其內部的人力資源應用程式。

Shabbir Darugar 是資深軟體開發工程師和專案組長在 Microsoft 處理其內部的人力資源應用程式。

Patrick Stanko 是首席專案經理在 Microsoft 處理其內部的人力資源應用程式。

因為有到下列的技術專家來檢閱這份文件： Tom Wisnowski