規劃驗證方法 (SharePoint Foundation 2010)

 

適用版本： SharePoint Foundation 2010

上次修改主題的時間： 2016-11-30

本文說明 Microsoft SharePoint Foundation 2010 所支援的驗證方法及驗證模式。驗證程序的目的在於確認使用者身分識別。確認使用者身分識別之後，授權程序即可決定使用者所能存取的網站、內容及其他功能。驗證模式將決定 SharePoint Foundation 2010 如何在內部使用帳戶。

本文內容：

• 支援的驗證方法

• 驗證模式 — 傳統或宣告式

• 實作 Windows 驗證

• 實作表單型驗證

• 實作 SAML 權杖型驗證

• 選擇 LDAP 環境的驗證

• 規劃 Web 應用程式的區域

• SAML 權杖型提供者的架構

支援的驗證方法

SharePoint Foundation 2010 支援舊版所包含的驗證方法，同時也新增以安全性聲明標記語言 (SAML) 為基礎的權杖型驗證選項。

方法	範例	附註
Windows	NTLM Kerberos 匿名 基本 摘要	目前並不支援 Windows 憑證驗證。
表單型驗證	輕量型目錄存取通訊協定 (LDAP) SQL 資料庫或其他資料庫 自訂或協力廠商成員資格與角色提供者
SAML 權杖型驗證	Active Directory Federation Services (AD FS) 2.0 協力廠商身分識別提供者 輕量型目錄存取通訊協定 (LDAP)	僅在使用 WS-同盟被動式設定檔的 SAML 1.1 中有提供支援

驗證模式 — 傳統或宣告式

SharePoint Foundation 2010 新增了宣告式驗證，這種驗證是建置在 Windows Identity Foundation (WIF) 上。您可以使用任何宣告式驗證支援的驗證方法。或者，您可以使用傳統模式驗證，這種驗證可支援 Windows 驗證。

建立 Web 應用程式時，您需選取兩種驗證模式之一 (宣告式或傳統模式)，以用於 Web 應用程式。

如果選取傳統模式，您可以實作 Windows 驗證，SharePoint Foundation 2010 就會將使用者帳戶視為 Active Directory 網域服務 (AD DS) 帳戶。

如果選取宣告式驗證，SharePoint Foundation 2010 會自動將所有帳戶變更成宣告身分識別，並為每位使用者產生宣告權杖。宣告權杖中包含關於使用者的宣告。Windows 帳戶將轉換成 Windows 宣告。表單型成員資格使用者則轉換成表單型驗證宣告。SAML 型權杖中的宣告可由 SharePoint Foundation 2010 使用。此外，SharePoint 開發人員及管理員可加入其他宣告以增強使用者權杖。例如，加入其他 SharePoint Foundation 2010 使用的宣告可增強使用者 Windows 帳戶及表單型帳戶。

下表簡要說明每種驗證模式支援的驗證類型。

類型	傳統模式驗證	宣告式驗證
Windows NTLM Kerberos 匿名 基本 摘要	是	是
表單型驗證 LDAP SQL 資料庫或其他資料庫 自訂或協力廠商成員資格與角色提供者	否	是
SAML 權杖型驗證 AD FS 2.0 Windows Live ID 協力廠商身分識別提供者 LDAP	否	是

SharePoint Foundation 2010 伺服器陣列可以混合包含使用這兩種模式的 Web 應用程式。服務不會區分使用者帳戶屬於傳統 Windows 帳戶或 Windows 宣告帳戶。因此，使用者若屬於設為混用不同驗證模式的網站，則無論 Web 應用程式設定使用的驗證模式為何，該使用者收到的搜尋結果將包括從其有權存取的所有網站搜尋到的結果。系統不會將使用者當成兩個不同使用者帳戶。這是因為無論為 Web 應用程式及使用者所選的模式為何，服務及服務應用程式都會在伺服器陣列之間的通訊中使用宣告身分識別。

但是，若使用者屬於一個以上 SharePoint Server Web 應用程式所辨識的使用者存放庫，在該使用者使用不同身分識別登入時，就會當成不同使用者帳戶。

下列指導將協助您決定要選擇何種模式：

• 若是新實作的 SharePoint Foundation 2010，請使用宣告式驗證。在這種驗證方式下，所有支援的驗證類型都可用於 Web 應用程式。即使您的環境只有 Windows 帳戶，也沒有實際理由要為新部署環境選取傳統模式驗證。無論選取哪種模式，實作 Windows 驗證的方式都一樣。在使用宣告式驗證模式下，實作 Windows 驗證模式並不需要額外執行其他步驟。

• 如果將舊版解決方案升級成 SharePoint Foundation 2010，而該解決方案僅使用 Windows 帳戶，則可以傳統模式驗證。這可讓區域與 URL 使用相同設計。

• 如果所升級的解決方案需要表單型驗證，唯一的選擇就是升級成宣告式驗證。

如果從舊版升級成 SharePoint Foundation 2010 且選取宣告式驗證，請注意下列考量事項：

• 可能需要更新自訂程式碼。您必須更新依賴或使用 Windows 身分識別的網頁組件或其他自訂程式碼。如果自訂程式碼使用 Windows 身分識別，請在程式碼更新之前使用傳統模式驗證。

• 要將許多 Windows 使用者移轉成宣告身分識別需要一些時間。在升級過程將 Web 應用程式從傳統模式變更成宣告式時，必須使用 Windows PowerShell 才能將 Windows 身分識別轉換成宣告身分識別。這個程序相當費時。請確認在升級過程中有足夠時間可完成此工作。

• 宣告式驗證目前不支援搜尋提醒。

宣告驗證是建置在 WIF 上。WIF 是一組 .NET Framework 類別，用以實作宣告式身分識別。宣告驗證需依賴一些標準 (例如 WS-同盟、WS-Trust) 及通訊協定 (例如 SAML)。如需宣告驗證的詳細資訊，請參閱下列資源：

• Windows 宣告式身分識別：Active Directory Federation Services 2.0、Windows CardSpace 2.0 及 Windows Identity Foundation 簡介 (白皮書)(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=198942&clcid=0x404)(可能為英文網頁)

• Windows Identity Foundation 首頁(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=198943&clcid=0x404)(可能為英文網頁)

您不必是宣告架構師，也能在 SharePoint Foundation 2010 中使用宣告驗證。但是，實作 SAML 權杖型驗證時，您需與宣告式環境的管理員協調，如本文後述。

實作 Windows 驗證

Windows 驗證方法的實作程序，與兩種驗證模式 (傳統或宣告式) 類似。為 Web 應用程式選擇宣告式驗證並不會使實作 Windows 驗證方法變得更複雜。本小節將摘要說明每種方法的程序。

整合式 Windows 驗證 — Kerberos 及 NTLM

Kerberos 通訊協定及 NTLM 都是整合式 Windows 驗證方法，這兩種方法可讓用戶端無縫地進行驗證，而不需經由提示要求認證。使用者若從 Windows 檔案總管存取 SharePoint 網站，將使用執行 Internet Explorer 程序所用的認證，進行驗證。根據預設，這些認證即是使用者用於登入電腦的認證。在整合式 Windows 驗證模式下存取 SharePoint Server 的服務或應用程式，將嘗試使用執行中之執行緒的認證 (根據預設，此即是該程序的身分識別) 進行驗證。

NTLM 是最簡單實作的 Windows 驗證方法。只要在建立 Web 應用程式時，選取此選項即可。

Kerberos 通訊協定是支援票證驗證的安全通訊協定。使用 Kerberos 通訊協定需再對環境進行額外設定。若要啟用 Kerberos 驗證，用戶端與伺服器電腦必須擁有連至網域金鑰發佈中心 (KDC) 的信任連線。若要設定 Kerberos 通訊協定，您需在安裝 SharePoint Foundation 2010 之前，先在 AD DS 中設定服務主要名稱 (SPN)。

下列步驟摘要說明設定 Kerberos 驗證的程序：

1. 為 SQL Server 服務帳戶在 AD DS 中建立 SPN，以設定 SQL 通訊所用的 Kerberos 驗證。

2. 為將使用 Kerberos 驗證的 Web 應用程式建立 SPN。

3. 安裝 SharePoint Foundation 2010 伺服器陣列。

4. 在該伺服器陣列中設定特定服務使用特定服務帳戶。

5. 建立將使用 Kerberos 驗證的 Web 應用程式。

如需詳細資訊，請參閱＜規劃 Kerberos 驗證 (SharePoint Server 2010)＞。

此外，以宣告驗證 Web 應用程式而言，還必須設定 Windows Token 服務的宣告以使用限制委派。要將宣告轉換成 Windows Token，就必須透過限制委派。若環境中有多個樹系，樹系之間必須有雙向信任，才能使用 Windows Token 服務的宣告。如需如何設定此服務的詳細資訊，請參閱＜設定 Windows Token 服務宣告的 Kerberos 驗證 (SharePoint Server 2010)＞。

Kerberos 驗證允許委派用戶端憑證，以存取後端資料系統，這在某些案例中，會需要額外設定。下表提供範例。

案例	額外設定
將用戶端身分識別委派給後端伺服器。 將 RSS 摘要顯示在已驗證的內容上。	為電腦及服務帳戶設定 Kerberos 限制委派。
Microsoft SQL Server Reporting Services (SSRS) 的身分識別委派	為 SQL Server Reporting Services 帳戶設定 SPN。 為 SQL Server Reporting Services 設定委派
SharePoint 中的 Excel Services 的身分識別委派	為執行 Excel Services 的伺服器設定限制委派 為 Excel Services 服務帳戶設定限制委派。

如需如何設定 Kerberos 驗證的詳細資訊，包括一般案例的詳細步驟，請參閱為 Microsoft SharePoint 2010 產品及技術設定 Kerberos 驗證 (白皮書)(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0x404)(可能為英文網頁)。

摘要及基本

若要實作摘要及基本驗證，需直接在 Internet Information Services (IIS) 上設定這些驗證方法。

實作表單型驗證

表單型驗證 (FBA) 是個身分識別管理系統，以 ASP.NET 成員資格與角色提供者驗證為基礎。在 SharePoint Foundation 2010 中，只有在您使用宣告式驗證時才能使用表單型驗證。

表單型驗證可用於依據儲存在 AD DS、資料庫 (例如 SQL Server 資料庫) 或 LDAP 資料庫儲存區 (例如 Novell eDirectory、Novell Directory Services (NDS) 或 Sun ONE) 中的認證，進行驗證。表單型驗證可根據從登入表單輸入的認證驗證，進行使用者驗證。未經驗證的要求會重新導向至登入頁面，使用者必須在該頁面提供有效認證再送出表單。如果可驗證該要求，系統會發出 Cookie，包含用於重新建立後續要求之身分識別的金鑰。

若在使用表單型驗證時，根據外部或不是以 Windows 為基礎的身分識別系統驗證使用者，則必須在 Web.config 檔案中登錄成員資格提供者及角色管理員。登錄角色管理員是 SharePoint Foundation 2010 的新需求。在舊版中，此為選擇性需求。SharePoint Foundation 2010 使用標準 ASP.NET 角色管理員介面，收集目前使用者的群組資訊。SharePoint Foundation 2010 的授權程序會將每一個 ASP.NET 角色視為一個網域群組。在 Web.config 檔案登錄角色管理員的方法，與登錄用於驗證之成員資格提供者的方法相同。

若要從 SharePoint 管理中心網站管理成員資格使用者或角色，您必須在 Web.config 檔案中為管理中心網站登錄成員資格提供者及角色管理員。您還必須在 Web.config 檔案中，為主控內容的 Web 應用程式登錄成員資格提供者及角色管理員。

如需如何設定表單型驗證的詳細資訊，請參閱下列資源：

• TechNet 文章：設定宣告式 Web 應用程式的表單型驗證 (SharePoint Server 2010)

• MSDN 部落格文章：宣告式驗證「速記表」第一部分(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=198944&clcid=0x404)(可能為英文網頁)

• MSDN 文章：SharePoint 產品及技術中的表單驗證 (第二部分)：成員資格及角色提供者範例(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=198945&clcid=0x404)(可能為英文網頁)

實作 SAML 權杖型驗證

若要進行 SAML 權杖型驗證，需與宣告式環境 (無論是貴組織本身內部環境或是合作夥伴環境) 的管理員進行協調。AD FS 2.0 即為宣告式環境的範例。

宣告式環境中包含一個身分識別提供者 Security Token Service (IP-STS)。IP-STS 會代表相關聯使用者目錄中的使用者發行 SAML 權杖。在權杖中，可包括關於使用者 (例如，使用者名稱及使用者所屬群組) 的任意數目宣告。

SharePoint Foundation 2010 在驗證使用者時，會利用 IP-STS 提供之權杖內的宣告。在宣告環境中，凡是接受 SAML 權杖的應用程式稱之為信賴憑證者 STS (RP-STS)。信賴憑證者應用程式在接收 SAML 權杖後，會使用其中所含的宣告來決定是否要授與用戶端存取所要求資源的權限。在 SharePoint 2010 產品 中，每個設為使用 SAML 提供者的 Web 應用程式，就會當成個別 RP-STS 項目新增至 IP-STS 伺服器中。SharePoint 伺服器陣列可包含數個 RP-STS 項目。

對 SharePoint 2010 產品 實作 SAML 權杖型驗證涵蓋下列程序，您需事先規劃這些程序：

1. 從 IP-STS 匯出權杖簽署憑證。此憑證稱之為 ImportTrustCertificate。將此憑證複製至 SharePoint Foundation 2010 伺服器陣列的伺服器電腦。

2. 定義要當成使用者唯一識別碼的宣告。此稱之為身分識別宣告。許多此程序的範例是以使用者電子郵件名稱當成使用者識別碼。請與 IP-STS 管理員協調，以決定正確的識別碼，因為只有 IP-STS 的擁有者才知道權杖中哪個值是每個使用者的唯一識別碼。識別使用者的唯一識別碼是宣告對應程序的一個過程。建立宣告對應需使用 Windows PowerShell。

3. 定義其他宣告對應。定義其他來自傳入權杖的哪個宣告將由 SharePoint Foundation 2010 伺服器陣列使用。使用者角色即是 SharePoint Foundation 2010 伺服器陣列中可用於權限資源的宣告範例。所有來自傳入權杖的宣告若沒有對應，將遭捨棄。

4. 使用 Windows PowerShell 建立新的驗證提供者，以匯入權杖簽署憑證。此程序會建立 SPTrustedIdentityTokenIssuer。在此過程中，您需指定身分識別宣告及您對應的其他宣告。您還必須建立並指定領域，以與您為 SAML 權杖型驗證設定的第一個 SharePoint Web 應用程式相關聯。建立 SPTrustedIdentityTokenIssuer 之後，您可以建立並新增更多領域，以供其他 SharePoint Web 應用程式使用。這就是設定多個 Web 應用程式使用同一個 SPTrustedIdentityTokenIssuer 的作法。

5. 對於已新增至 SPTrustedIdentityTokenIssuer 的每一個領域，您必須在 IP-STS 上建立 RP-STS 項目。這項作業可在建立 SharePoint Web 應用程式之前完成。無論如何，您必須在建立 Web 應用程式之前規劃 URL。

6. 建立新的 SharePoint Web 應用程式，並設為使用新建立的驗證提供者。一旦為 Web 應用程式選取宣告模式，此驗證提供者就會變成一個選項顯示在管理中心中。

您可以設定多個 SAML 權杖型驗證提供者。但是，您只能在伺服器陣列中使用權杖簽署憑證一次。所有已設定的提供者都會變成選項顯示在管理中心中。來自不同受信任 STS 環境的宣告將不會產生衝突。

如果您對合作夥伴公司實作 SAML 權杖型驗證，且貴組織本身環境也包括 IP-STS，建議您與內部宣告環境的管理員一起合作，讓您內部 IP-STS 與合作夥伴 STS 之間能建立真正關係。這種作法不需要對您的 SharePoint Foundation 2010 伺服器陣列新增其他驗證提供者，同時也可讓您的宣告管理員管理整個宣告環境。

注意

如果 SharePoint Foundation 2010 伺服器陣列中有多部設定負載平衡的網頁伺服器，而您在其中使用 SAML 權杖型驗證搭配 AD FS，這可能會影響用戶端網頁檢視效能及功能。當 AD FS 提供驗證權杖給用戶端，該權杖便會提交至 SharePoint Foundation 2010 供每個受限權限頁面元素使用。如果負載平衡解決方案並未使用相關性，每個受到保護的元素便需向多個 SharePoint Foundation 2010 伺服器驗證，如此可能會導致權杖遭拒。一旦權杖遭拒，SharePoint Foundation 2010 會將用戶端重新導向，回到 AD FS 伺服器重新驗證。發生此情況之後，AD FS 伺服器可能會拒絕在短時間內發出的多個要求。此行為是原本的設計，這是為了免遭拒絕服務攻擊。如果對效能發生負面影響，或是未能完整載入頁面，請將網路負載平衡設為單一相關性，如此可將對 SAML 權杖的要求隔離在單一網頁伺服器上。

如需如何設定 SAML 權杖型驗證的詳細資訊，請參閱下列資源：

• TechNet 文章：設定使用 SAML 安全性憑證的驗證 (SharePoint Server 2010)

• MSDN 部落格文章：宣告式驗證「速記表」第二部分(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=198946&clcid=0x404)(可能為英文網頁)

• TechNet 部落格文章：規劃 SharePoint 2010 的宣告式驗證考量(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=198947&clcid=0x404)(可能為英文網頁)

• TechNet 部落格文章：為 SharePoint 2010 宣告驗證應用程式建立身分識別及角色宣告(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=198948&clcid=0x404)(可能為英文網頁)

• TechNet 部落格文章：如何在單一 SharePoint 2010 伺服器陣列中建立多個宣告驗證 Web 應用程式(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=198949&clcid=0x404)(可能為英文網頁)

選擇 LDAP 環境的驗證

若要實作 LDAP 環境，可以使用表單型驗證或 SAML 權杖型驗證。建議您使用表單型驗證，因為這種驗證複雜性較低。不過，如果環境支援 WS-同盟 1.1 及 SAML 權杖 1.1，則建議使用 SAML。若 LDAP 提供者未與 ADFS 2.0 相關聯，則不支援設定檔同步處理。

規劃 Web 應用程式的區域

區域代表存取 Web 應用程式中同一個網站的不同邏輯路徑。每個 Web 應用程式最多可包含五個區域。建立 Web 應用程式時，就會建立預設區域。若要建立其他區域，只要擴充 Web 應用程式，並從其餘區域名稱中選取其中之一：內部網路、外部網路、網際網路或自訂。

在舊版中，區域的功用是針對來自不同網路或驗證提供者的使用者，實作不同類型的驗證。在目前版本中，宣告驗證可允許在同一個區域中實作多種驗證類型。

對於區域的規劃，取決於您為 Web 應用程式選取下列何種模式：

• 傳統模式 — 類似於舊版的是，每個區域僅能實作一種驗證類型。但是，在目前版本中，若選取傳統模式，則只能實作 Windows 驗證。因此，必須使用多個區域才能實作多種 Windows 驗證類型，或實作同一種 Windows 驗證類型比對不同 Active Directory 儲存區。

• 宣告驗證 — 可在單一區域中實作多個驗證提供者。也可以使用多個區域。

在單一區域中實作多種驗證類型

如果使用的是宣告驗證，並同時實作多種驗證類型，建議您在預設區域上實作多種驗證類型。這可讓所有使用者得到相同 URL。

當在同一區域實作多種驗證類型時，將有下列限制：

• 只能在一個區域中實作一個表單型驗證的執行個體。

• 管理中心需允許您同時使用整合式 Windows 方法及基本驗證，否則無法在同一區域上實作多種 Windows 驗證類型。

如果伺服器陣列設定了多個 SAML 權杖型驗證提供者，在您建立 Web 應用程式或新的區域時，這些提供者都會變成選項。您可以在同一個區域上設定多個 SAML 提供者。

下圖說明合作夥伴共同作業網站預設區域上所實作的多種驗證類型。

在此圖中，來自不同目錄儲存區的使用者使用相同 URL 存取合作夥伴網站。以虛線方框框住合作夥伴公司，表示使用者目錄與預設目錄所設定的驗證類型之間的關係。如需此設計範例的詳細資訊，請參閱＜設計範例：公司部署 (SharePoint Server 2010)＞。

規劃編目內容

編目元件需使用 NTLM 存取元件。必須至少有一個區域設為使用 NTLM 驗證。如果預設區域並未設定 NTLM 驗證，編目元件可以使用其他設為使用 NTLM 驗證的區域。

實作多個區域

若要為 Web 應用程式實作多個區域，請使用下列準則：

• 使用預設區域實作最安全的驗證設定。若某要求無法與特定區域相關聯，將會套用預設區域的驗證設定及其他安全性原則。預設區域是一開始建立 Web 應用程式時所建立的區域。通常會針對使用者存取，設計最安全的驗證設定。因此，使用者可能會存取預設區域。

• 使用能夠提供使用者存取所需的最少區域數目。每個區域都要與新 IIS 網站及網域產生關聯，以便存取 Web 應用程式。只有在需要新的存取點時才新增。

• 請確定至少有一個區域設為使用 NTLM 驗證，以供編目元件使用。若非必要，請勿建立索引元件的專用區域。

下圖說明實作多個區域，以滿足合作夥伴共同作業網站的多種驗證類型需求。

在此圖中，預設區域係供遠端員工使用。每個區域都有不同的相關聯 URL。員工視其位於辦公室工作或遠端工作，而使用不同區域。如需此設計範例的詳細資訊，請參閱＜設計範例：公司部署 (SharePoint Server 2010)＞。

SAML 權杖型提供者的架構

SAML 權杖型提供者的實作架構包括下列元件：

SharePoint Security Token Service   此服務會建立伺服器陣列所用的 SAML 權杖。此服務會在伺服器陣列的所有伺服器上自動建立並啟動。此服務用於伺服器陣列之間的通訊，因為所有伺服器陣列之間的通訊都是使用宣告驗證。此服務還用於使用宣告驗證之 Web 應用程式所實作的驗證方法，包括 Windows 驗證、表單型驗證及 SAML 權杖型驗證。您必須在部署期間設定 Security Token Service。如需詳細資訊，請參閱＜設定 Security Token Service (SharePoint Server 2010)＞。

權杖簽署憑證 (ImportTrustCertificate)   這個憑證是從 IP-STS 匯出。此憑證會複製至伺服器陣列的一部伺服器上。一旦您使用此憑證建立 SPTrustedIdentityTokenIssuer，就無法再用此憑證建立其他 SPTrustedIdentityTokenIssuer。若想使用此憑證建立不同 SPTrustedIdentityTokenIssuer，則必須先刪除現有的 SPTrustedIdentityTokenIssuer。在刪除現有的 SPTrustedIdentityTokenIssuer 之前，必須先從任何可能使用它的 Web 應用程式中解除彼此關聯。

身分識別宣告   身分識別宣告是來自 SAML 權杖的宣告，它是使用者的唯一識別碼。只有 IP-STS 的擁有者才知道權杖中哪個值是每個使用者的唯一識別碼。在進行對應所有所需宣告的程序期間中，會建立身分識別宣告，做為一般宣告對應。做為身分識別宣告之用的宣告，是在建立 SPTrustedIdentityTokenIssuer 時宣告。

其他宣告   這些宣告包括 SAML 票證中用以描述使用者的其他宣告，其中可包括使用者角色、使用者群組或其他種類的宣告，例如年齡。所有宣告對應都會建立成物件形式，並在 SharePoint Foundation 伺服器陣列的伺服器之間複寫。

領域   在 SharePoint 領域架構中，URI 或 URL 若與設為使用 SAML 權杖型提供者之 SharePoint Web 應用程式相關聯，即為領域。當在伺服器陣列上建立 SAML 型驗證提供者，您需指定 IP-STS 要辨識的領域，或 Web 應用程式 URL (一次指定一個)。第一個領域是在您建立 SPTrustedIdentityTokenIssuer 時指定。其他領域則可在建立 SPTrustedIdentityTokenIssuer 之後再新增。指定領域的語法類似下列語法：$realm = "urn:sharepoint:mysites"。對 SPTrustedIdentityTokenIssuer 新增領域之後，您必須對 IP-STS 伺服器上的領域建立 RP-STS 信任。此程序包含指定 Web 應用程式的 URL。

SPTrustedIdentityTokenIssuer   這個物件是建立在包含進行 IP-STS 通訊並從此通訊中接收權限所需之值的 SharePoint 伺服器陣列上。在建立 SPTrustedIdentityTokenIssuer 時，您需指定要使用的權杖簽署憑證、第一個領域、代表身分識別宣告的宣告，以及其他任何宣告。來自 STS 的權杖簽署憑證只能與一個 SPTrustedIdentityTokenIssuer 產生關聯。但是，建立 SPTrustedIdentityTokenIssuer 之後，您還是可以為其他 Web 應用程式新增更多領域。對 SPTrustedIdentityTokenIssuer 新增領域之後，還必須將它當成信賴憑證者新增至 IP-STS。SPTrustedIdentityTokenIssuer 物件會在 SharePoint Foundation 伺服器陣列的伺服器之間複寫。

信賴憑證者 Security Token Service (RP-STS)   在 SharePoint Foundation 2010 中，每個設為使用 SAML 提供者的 Web 應用程式都會當成 RP-STS 項目新增至 IP-STS 伺服器。SharePoint Foundation 伺服器陣列可包含多個 RP-STS 項目。

身分識別提供者 Security Token Service (IP-STS)   宣告環境中的這個 Security Token Service 會代表相關使用者目錄中的使用者發行 SAML 權杖。

下圖說明 SharePoint 2010 產品 宣告架構。

SPTrustedIdentityTokenIssuer 物件是使用多個參數所建立。下圖說明主要參數。

如此圖所示，SPTrustedIdentityTokenIssuer 只可包含一個身分識別領域、一個 SignInURL 參數，及一個 Wreply 參數。不過，它可以包含多個領域及多個宣告對應。SignInURL 參數可指定將使用者要求重新導向的 URL，以向 IP-STS 進行驗證。有些 IP-STS 伺服器會需要 Wreply 參數，這個參數可設為 True 或 False，預設值為 False。只有在 IP-STS 需要的情況下，才能使用 Wreply 參數。