• 發行項

本文章是由機器翻譯。

身分識別解決方案中的 AD FS 2.0

在身分識別解決方案中使用 Active Directory Federation Services 2.0

Zulfiqar Ahmed

下載程式碼範例

身為開發人員您或許知道一些有關 Windows 識別基礎 (WIF)，以前稱為 「 Geneva Framework 」，它提供了強大的 API 宣告啟用您的應用程式，並建立自訂的安全性權杖服務。 對您較少熟悉或許是 Active Directory 聯盟服務版本 2.0 (AD FS 2.0)、 原先程式碼命名 「 Geneva 伺服器，」 也就是一個可供企業的聯盟和單一登入 (SSO) 解決方案。 AD FS 2.0 是的 AD FS 1.0，演進，而且它支援同時主動 (WS-Trust) 和被動 (WS-聯盟和 SAML 2.0) 案例。

本文章中我開始就擁有 AD FS 2.0 的概觀，並提供深入瞭解如何開發人員可以使用其身分識別方案中的 AD FS 2.0。 焦點是在 AD FS Beta 2 版本為基礎的 2.0 的語彙基元發佈功能上。 您可以看到從 的 圖 1，此語彙基元發佈是只有一小段 AD FS 2.0，但它是其中一個特定聯盟識別向移動的.NET 開發人員感興趣。 architecturally，AD FS 2.0 建置 WIF 的頂端與 Windows Communication Foundation (WCF)，所以如果您 ’re 熟悉這些技術，您應該覺得右在家使用 AD FS 2.0。


圖 1 的 AD FS 2.0 架構

AD FS 2.0 的概觀

在高層次 AD FS 2.0 會是 的 圖 2 所示的服務集合。

AD FS 2.0 的核心是安全性權杖服務 (STS)，做為屬性儲存區會使用 Active Directory 作為其識別身分存放區] 和 [輕量型目錄存取通訊協定 (LDAP)]、 [SQL] 或 [自訂存放區。 在 AD FS 2.0 STS 可以發出安全性語彙基元 (Token) 給呼叫端使用包括 WS-信任的各種協定 WS-聯盟和安全性判斷提示已標記語言 (SAML) 2.0。 AD FS 2.0 STS 也支援 SAML 1.1 和 2.0 SAML 語彙基元的格式。

AD FS 2.0 的設計是具有乾淨分離電線通訊協定和內部的語彙基元發佈機制之間的數字。 不同電線通訊協定會轉換成在系統進入的標準化的物件模型，而內部 AD FS 2.0 使用相同的物件模型的每個通訊協定。 此區隔可讓 AD FS 2.0 提供乾淨的擴充性模型，獨立的不同電線通訊協定的複雜性。 進一步的詳細資料的 AD FS 2.0 擴充性將會提供之前要 RTM AD FS 2.0 SDK 中。


圖 2 的 AD FS 2.0 元件

為識別提供者的 AD FS 2.0

您可以使用 AD FS 2.0 在幾個常見的案例。 最簡單且最常見案例是使用 AD FS 2.0 為識別提供者，讓它可以發出它管理識別身分的 SAML 語彙基元。 為此，必須建立新的信賴。 信賴 AD FS 2.0 中的是表示應用程式 (網站或 Web 服務) 和包含的所有安全性相關資訊，例如加密憑證，依此類推宣稱轉換規則。

正在設定一個信賴

設定 AD FS 2.0 透過一個新信賴是很容易的。 您可以透過 [AD] 的 [原則] 節點來存取新增仰賴合作對象精靈 」 完成-開始 2.0 管理] 主控台。 一次那里，您或您的系統管理員需要在精靈 的 圖 3 所示的 [選取資料來源] 頁面中指定適當的資料來源。


圖 3 的選取資料來源頁新增依賴的組件精靈

前兩個選項可讓您自動設定信賴使用聯盟中繼資料。 如果您有存取信賴 ’s 聯盟中繼資料，在網路上或在本機檔案，選取這些兩個選項之一因為它們是比較不容易發生錯誤、 它們自動化整個程序而且他們自動更新如果信賴的任何詳細資料在未來變更。 這些選項是主要的改進透過 AD FS 1.0，doesn’t 提供這類自動化程序。

第三個選項需要您手動輸入所有的組態詳細資料。 只有當 don’t 有聯盟中繼資料的權限存取，或是您想要控制依賴的合作對象組態的詳細資訊，請使用這個選項。

它 ’s 指示執行透過 「 手動輸入依賴合作對象組態 」 選項，只是使您可以看到所需來設定新的信賴的所有步驟。 在精靈的下一個的幾個頁面中, 會要求您選擇設定檔 — 選擇 AD FS 2.0 設定檔如果您想要支援同時瀏覽器為基礎和以 WCF 基礎的用戶端或 AD FS 1.x 設定檔，如果您只需要 AD FS 1.x 互通性，而且 don’t 支援主動 (WCF，CardSpace) 用戶端 ； 設定用來加密語彙基元，以便只信賴使用相對應的私密金鑰可以解密，並使用發行的權杖; 憑證並設定識別項，用來識別這個信賴中所有的語彙基元發佈要求。

一旦您完成新增仰賴合作對象精靈，規則編輯器 」 工具會開啟。 此工具在您設定宣告發行和轉換規則。 圖 4 顯示設定為使用單一宣告其值發行語彙基元 「 規則編輯器 」 工具將會擷取從主要屬性儲存區。 請注意顯示名稱屬性會對應到指定的名稱宣告。 AD FS 2.0 引入了一個新、 文字定義域專屬語言，可讓您定義衍生宣告發行和轉換程序的簡單規則。 每個規則條件和動作和組成結束 — 做為在 [c] = > 一; — 以分號。 轉換邏輯是一系列的語彙基元發佈程序期間依序執行的規則。 的 圖 4，簡易的檢視] 索引標籤會提供使用者介面，以定義這些規則。 進階檢視] 索引標籤可讓您直接使用定義域專屬語言的作者規則。


圖 4 的 規則編輯器工具

本範例說明了在 AD FS 2.0 設定受信任的信賴是多麼簡單。 這個時候當 AD FS 2.0 接收語彙基元發佈要求，它從電線通訊協定 (比方說 「 WS-信任的情況下 appliesTo 元素) 擷取的識別項並使用它來查詢目標信賴。 一旦找到一個信賴精靈中的設定用來衍生語彙基元發佈邏輯。

現在 let’s 看看如何使用 WCF 來為這個信賴從 AD FS 2.0 要求語彙基元。

要求使用 WCF 的語彙基元

有兩個選項可用來與 AD FS 2.0 STS 使用 WCF 互動：

  • 明確地取得做為 「 WS-信任用戶端的語彙基元
  • 設定 WCF 用戶端，讓基礎結構隱含地取得語彙基元做為呼叫的一部分

在明確選項 WSTrustClient 類別會提供一個簡單且直接 API 來要求語彙基元 (Token) 從 STS 使用 WS-Trust] 通訊協定，如下所示。

string baseUri = "https://bccoss.com/";

WindowsWSTrustBinding binding = new WindowsWSTrustBinding(SecurityMode.Transport);

WSTrustClient tokenClient = new WSTrustClient(binding,
    new EndpointAddress(baseUri + "Trust/2005/WindowsTransport/"),
    TrustVersion.WSTrustFeb2005,
    new ClientCredentials());

//create a token issuance issuance
RequestSecurityToken rst =
    new RequestSecurityToken(WSTrustFeb2005Constants.RequestTypes.Issue);
//Relying Party’s identifier
rst.AppliesTo = new EndpointAddress("http://local.zamd.net/");
//call ADFS STS
SecurityToken token = tokenClient.Issue(rst);

這個程式碼會要求使用 Windows 驗證以傳輸的安全性語彙基元。 如您所見，明確模式中您會取得未經處理語彙基元您可以使用稍後在呼叫服務的存取。 比方說智慧型用戶端應用程式中您可能會在應用程式啟動或登入時間取得不同的服務的語彙基元，、 將其儲存語彙基元快取中然後再使用整個應用程式的存留期 (Lifetime) 的它們呼叫不同的後端服務。 而且，在許多服務住在共用相同的憑證在同一個邏輯的安全性界限的案例中，您可以使用 [明確模式] 以取得單一的語彙基元，然後呼叫那些服務時使用它。

 在其中您通常可以信賴 ’s 私密金鑰的存取到測試環境中，您可以使用下列程式碼來從傳回的語彙基元擷取 SAML 判斷提示。

//Private Key certificate of RP (local.zamd.net)
X509Certificate2 rpCertificate = new X509Certificate2("zamd.net.pfx", "pwd");
string assertion = Util.ExtractSAMLAssertion(token, rpCertificate);

<saml:Attribute AttributeName="givenname" AttributeNamespace="https://schemas.xmlsoap.org/ws/2005/05/identity/claims">
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue>
</saml:Attribute>

SAML 語彙基元 (Token) 包含只宣告為這個特定的信賴設定。 參照回 圖 4 ，顯示了如何此信賴 ’s 輸出語彙基元 (Token) 已設定為傳回單一屬性。 您可以編輯要在輸出中包含多個宣告的信賴 ’s 組態，您應該看到全部的反映這裡。 您也可以使用宣告原則語言直接以定義豐富的轉換和篩選邏輯。

WSTrustClient API 及新 WSTrust 繫結是 WIF 的一部份讓上述程式碼來處理，WIF 必須安裝在用戶端上。 您也可以使用 WCF API 直接以明確地取得一個語彙基元，但簡化及方便使用 WIF 優惠可以採取關閉您的待辦事項清單的一項工作。

的 圖 5 中程式碼，IssuedSecurityTokenProvider 就 WSTrustClient WCF 等於並用通常由 wsFederationBinding 要求您的名義語彙基元 (Token) 時。 因為它 ’s 公用 API，您可以自由它在您的程式碼中應該您需要存取原始的語彙基元。 CustomBinding 等於 WindowsWSTrustBinding。

圖 5 使用來存取未經處理的語彙基元 IssuedSecurityTokenProvider

sstring baseUri = "https://bccoss.com/";

//Limited edition of WSTrustClient:)
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider();
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer();

//Relying Party's identifier
provider.TargetAddress = new EndpointAddress(new Uri("http://local.zamd.net"));
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri + "Trust/2005/WindowsTransport/"));

provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
provider.MessageSecurityVersion = MessageSecurityVersion.
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

HttpsTransportBindingElement tbe = new HttpsTransportBindingElement();
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate;
CustomBinding stsBinding = new CustomBinding(tbe);

provider.IssuerBinding = stsBinding;
provider.Open();
//Request a token from ADFS STS
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));

在隱含選項您可以使用標準 wsFederationHttpBinding 的大小寫 WCF 基礎結構無障礙地取得語彙基元，並將其傳送至服務呼叫的一部分。 每當您建立新的 WCF Proxy，並用來呼叫服務，基礎結構會為您擷取新的語彙基元。 很明顯地，這是在某些案例中的麻煩。 的 圖 6 中的程式碼會設定為需要從 AD FS 2.0 語彙基元 (Token) 的虛構 EmployeeService。

圖 6 使用 wsFederationHttpBindingto 取得一個語彙基元隱含

<system.serviceModel>
  <services>
    <service name="EmployeeService.EmployeeService">
      <endpoint address="http://localhost:9990/ES"
        binding="ws2007FederationHttpBinding"
        contract="EmployeeServiceContract.IEmployeeService"
        bindingConfiguration="adfsFed"/>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="adfsFed">
        <security mode="Message">
          <message negotiateServiceCredential="false" >
            <issuer address="https://bccoss.com/Trust13/KerberosMixed"
               binding="customBinding" bindingConfiguration="MixedKerberos"/>
          </message>
        </security>
      </binding>
     </ws2007FederationHttpBinding>
     <customBinding>
       <binding name="MixedKerberos">
         <security authenticationMode="KerberosOverTransport"/>
         <httpsTransport/>
       </binding>
     </customBinding>
   </bindings>
</system.serviceModel>
WCF 的對應 AD FS 2.0 概念

AD FS 2.0 的核心責任是已驗證的使用者發出語彙基元。 可以使用不同的驗證機制 (例如 Windows 驗證)，驗證的使用者。 在 [管理] 主控台中選取 [結束點] 節點，可以看出所有支援的驗證機制。

您發現兩個熟悉 WCF 安全性概念為端點節點內的欄名：

  • 驗證類型是 AD FS 2.0 相等的 WCF clientCredentialType 術語。
  • 安全性模式選擇是傳輸、 郵件或混合。 混合相當 AD FS 2.0 的 WCF ’s TransportWithMessageCredentials。

這兩個值的不同組合又會公開使用不同的端點，並且您選擇特定端點，根據您的驗證需求。 如果需要使用使用者名稱/密碼進行驗證，例如可選擇清除密碼驗證端點。

對於 AD FS 2.0 STS 回到位址、 繫結及合約 (ABC) 在 WCF，對應這些概念，您會取得下列的對等用法：

  • 地址 = AD FS 2.0 基底位址 + 端點 ’s URL 路徑
  • 繫結 = 端點 ’s 安全性模式 + 驗證類型
  • 合約 = 標準 WS-信任通訊協定

另一個 STS 的 AD FS 2.0 進行聯盟

除了建立依賴合作對象，您可以建立信任關係 AD FS 2.0 和自訂 STS 或另一個 AD FS 2.0 之間。 比方說如果您已經 STS，驗證使用者，並發出語彙基元 (Token) 您可以只新增它為信任的識別身份提供者內 AD FS 2.0，這將會接受由 [STS 所發行的語彙基元 (Token)。

正在設定身份識別提供者

在 AD FS 2.0 的新的受信任的識別提供者的設定是類似設定新的信賴。 您使用 [新增身分識別提供者精靈看起來和方式作業很多新增仰賴合作對象精靈 」 (請參閱回 的 圖 3)。

要到達設定識別元頁，選擇手動設定選項 (如 的 圖 3 的步驟) 一次，然後選取 [AD FS 2.0 設定檔，在 [選擇設定檔] 頁面上。 在 [設定 URL] 頁面上保持預設的設定。 您接著選擇 [身份識別提供者的 [識別項和公開金鑰憑證，並完成精靈來註冊新的身份識別提供者。

要求使用 WCF 的語彙基元

一旦您註冊一個額外的身份識別提供者與 AD FS 2.0 邏輯架構看起來 的 圖 7 所示的設定。


圖 7 的 AD FS 2.0 與其他識別提供者架構

的 [圖 8] 中的程式碼可讓您取得語彙基元明確，讓您快取在本機的語彙基元，並將其傳送至服務，視需要有彈性。

圖 8 使用 IssuedTokenWSTrustBinding 絕不取得一個語彙基元

string adfsStsUri = "http://bccoss.com/Trust/2005/IssuedTokenAsymmetricBasic256";

//binding for local STS(IP-STS)
WSHttpBinding localStsBinding = new WSHttpBinding(SecurityMode.Message);

localStsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
localStsBinding.Security.Message.EstablishSecurityContext = false;
localStsBinding.Security.Message.NegotiateServiceCredential = false;

EndpointAddress localStsEpr = new EndpointAddress(
   new Uri("http://localhost:9000/STS/"),
   new X509CertificateEndpointIdentity(new X509Certificate2(@"MyCustomSTSPublicKey.cer")));

//This binding will transparently acquire all the intermediate tokens as part of the call. (R-STS)
IssuedTokenWSTrustBinding fedBinding = new IssuedTokenWSTrustBinding(localStsBinding, localStsEpr);
fedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;

EndpointAddress adfsStsEpr = new EndpointAddress(
    new Uri(adfsStsUri),
    new X509CertificateEndpointIdentity(new X509Certificate2("AdfsStsPubicKeyOnly.cer")));

WSTrustClient trustClient = new WSTrustClient(fedBinding, adfsStsEpr, TrustVersion.WSTrustFeb2005,
null);

//Create a security token request
RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);
//Set Relying Party's identifier accordingly
rst.AppliesTo = new EndpointAddress("http://local.zamd.net");

SecurityToken finalToken = trustClient.Issue(rst);

IssuedTokenWSTrustBinding 是 wsFederationHttpBinding 非常類似，因為它會隱藏的中繼語彙基元 (Token) 的所有複雜性無障礙地向 IP STS 取得中繼的語彙基元，接著傳送到 R STS 作為驗證權杖。

的 圖 9 中程式碼使用 wsFederationHttpBinding 啟用 WCF 用戶端隱含地取得語彙基元服務呼叫的一部分。

請注意我 /IssuedTokenMixedSymmetricBasic256 端點與交談時使用一個 customBinding。 標準 wsFederationHttpBinding doesn’t 這裡運作，因為它會嘗試建立與此 AD 不相容 「 安全工作階段 FS 2.0 端點。 若要聯盟 AD FS 2.0 的 WCF 用戶端，您必須使用一個 customBinding 或其中一個繫結新 WS 信任基礎，這個繫結船有 WIF。

圖 9 來取得一個語彙基元隱含使用 wsFederationHttpBinding

<system.serivceModel>
   <bindings>
      <wsFederationHttpBinding>
         <binding name="R-STS">
            <security mode="Message">
               <message>
                  <issuer address="https://bccoss.com/Trust/2005/IssuedTokenMixedSymmetricBasic256" binding="customBinding" bindingConfiguration="IP-STS"/>
               </message>
            </security>
         </binding>
      </wsFederationHttpBinding>

      <customBinding>
         <binding name="IP-STS">
            <security authenticationMode="IssuedTokenOverTransport">
               <issuedTokenParameters>
                  <issuer address="http://localhost:9000/CustomSTS" binding="wsHttpBinding"/>
               </issuedTokenParameters>
            </security>
            <httpsTransport/>
         </binding>
      </customBinding>
   </bindings>

   <client>
      <endpoint address="http://localhost:9990/ES" binding="wsFederationHttpBinding" bindingConfiguration="R-STS"
contract="ServiceReference1.IEmployeeService" name="WSFederationHttpBinding_IEmployeeService"/>
      </client>
</system.serviceModel>

AD FS 2.0 和瀏覽器用戶端

AD FS 2.0 有頂級支援 Web 單一登入 (WebSSO) 和使用 「 WS-聯盟和 SAML 2.0 的通訊協定的聯盟。

在概念上，WS-聯盟和 SAML 通訊協定是類似即使它們具有不同電線表示法。 與 WS-聯盟 Wire 格式密切相關 WS-Trust 通訊協定所以伺服主動和被動 (瀏覽器為基礎) 的用戶端時，這會是邏輯的選擇。 SAML 通訊協定跨不同廠商有更好的互通性。 AD FS 2.0 原生支援這兩個這些通訊協定。 它 ’s 停在安全性邊界是單一通訊協定 (比方說 「 WS-聯盟)、 使用 AD FS 2.0 作為通訊協定保險經紀人集線器傳入或傳出 SSOs 是個不錯的作法。

let’s 考慮範例。 假設您有一個簡單的 ASP.NET 應用程式，僅要通過驗證的使用者提供的功能。 當作獨立的應用程式驗證邏輯實作為 「 應用程式的一部份，並與這個應用程式互動會遵循 的 圖 10 所示的步驟。


圖 10 的 簡易的 ASP.NET 應用程式中的直接驗證

此處在一般 ASP.NET 驗證機制，(例如表單驗證會被實作。 我們的目標是要從這個應用程式中擷取驗證功能，並改用 AD FS 2.0。

AD 中 FS 2.0 安裝程式] 所示 圖 11 應用程式會變成內部 AD FS 2.0 信賴一個受信任和因此信任語彙基元 (Token) 發出的 AD FS 2.0。 應用程式會用來執行的語彙基元 (Token) 剖析、 依此類推解壓縮宣告所有重型 lifting WIF。 應用程式使用標準的 IIdentity/IPrincipal 抽象概念提供身分識別資訊。

在 AD FS 2.0 分散式的驗證比直接驗證更彈性，而且它提供了一些主要的好處：

  • 驗證被 externalized 從應用程式，以便驗證機制可以 (比方說從 Kerberos 的使用者名稱) 不會影響應用程式變更。
  • 宣告為基礎的模型的彈性可以應用程式從不同來源擷取該資訊本身而不直接提供所有必要的資訊，以 (做為語彙基元的一部分) 應用程式。

Beta 2 版本的 WIF 引進了新的專案範本，可讓您輕易地 externalize STS 的應用程式 ’s 驗證邏輯。 以撰寫本文的這些範本可只用於 C#。


圖 11 分散式 AD FS 2.0 中的驗證

externalizing 驗證邏輯

如果要 externalize 應用程式 ’s 驗證邏輯，使用 [Microsoft Visual Studio 對話方塊新網站。 選取要與 WIF 建立標準的 ASP.NET Web 站台預先設定的 [宣告感知的 Web 站台範本。

要啟動聯盟公用程式 」 精靈 圖 12 所示在方案總管] 中的 [網站] 節點上按一下滑鼠右鍵，然後選取 [從功能表的 [修改 STS 參考]。


圖 12 的 聯盟的公用程式

為使本範例讓我們選擇 「 使用現有的 STS 」] 選項，並為 [STS 指定 AD FS 2.0。 此精靈需要中繼資料文件的 URL，自動執行所有必要的組態。 使用做為內部 AD FS 2.0 端點的中繼資料文件 URL。

聯盟中繼資料包含如 STS 簽署憑證，提供宣告和語彙基元發佈 URL 的重要資訊。 不必標準化的格式，如這項資訊可讓自動化 STS 之間的信任建立工具及仰賴合作對象。

在精靈的 [摘要] 頁面摘要說明即將在 web.config 檔案中所做的變更。

聯盟公用程式 」 精靈正在設定 WIF 在您的網站，以提供下列功能：

  • 所有未經驗證的要求將被重新導向到 AD FS 2.0。
  • 包含有效的語彙基元任何要求，將處理，且身分識別資訊將會呈現給 ClaimsIdentity/ClaimsPrincipal 形式應用程式。 應用程式會繼續存取使用標準的 IPrincipal/IIdentity 抽象概念，無論該資訊的來源的識別資訊。

測試應用程式之前, 您需要做一個變更 AD FS 2.0 上的最後一個組態。 您必須將額外的端點加入至瀏覽器用戶端的信賴。 此端點是必要的因為一旦 AD FS 2.0 已處理語彙基元發佈要求，兩項資訊所需之前可以傳送至瀏覽器語彙基元：

  • 應該傳送語彙基元，地址
  • 通訊協定 (SAML 或 WS-聯盟) 應該傳送哪些語彙基元，

您可以新增被動的端點來測試 RP 內容] 對話方塊的 [結束點] 索引標籤中的信賴。 比方說如果您選取 「 WS-聯盟為端點類型，AD FS 2.0 會傳送語彙基元 (Token) 回給使用 「 WS-聯盟通訊協定的信賴。 內部依賴合作對象之原本就能夠了解 「 WS-聯盟通訊協定的 WIF 會處理這些語彙基元 (Token)。

現在當想瀏覽至應用程式您會自動重新導向至驗證 AD 完成-開始 2.0，您可以在這裡選擇驗證方法您想要使用：Windows 整合式的驗證，憑證驗證或使用者名稱/密碼表單。

一旦驗證成功，您 — 連同 AD FS 2.0 所發出的語彙基元 — 會被重新導向回至應用程式。 WIF 處理此語彙基元，並讓最終的身分識別宣告表單) 中也可以使用應用程式使用標準的 ASP.NET 機制 (比方說 Page.User)。

瀏覽器為基礎的聯盟

您可以藉由加入一個額外的信任身份識別提供者，將基本的外部驗證案例延伸至聯盟案例。 識別提供者選項就會顯示在驗證過程。

您可以使用 AD FS 2.0 驗證或其他受信任的身份識別提供者。 如果您選取 [不同的身份識別提供者您會重新導向至該識別提供者而，在驗證成功時重新導向到 AD FS 會然後驗證您根據語彙基元 (Token) 由受信任的身份識別提供者所發行的 2.0。

功能強大的組合

如您看過本文中，AD FS 2.0 STS 提供一個只是與宣告-啟用 WCF 服務和瀏覽器架構的應用程式的現成解決方案。 STS 本身是只有一個小型的 AD FS 2.0，其中也包括 CardSpace，佈建系統、 規則為基礎的宣告轉換引擎、 自動信任管理基礎結構、 管理與組態服務和其各自的工具。 連同 WIF，AD FS 2.0 會在 Windows 平台上建立功能強大的組合來程式識別方案。

Zulfiqar Ahmed 英國應用程式開發顧問 (ADC) 小組的資深顧問，而且可以達到在 http://zamd.net。