AD FS 2.0 在身份标识解决方案中的作用

  • 项目

在身份标识解决方案中使用 Active Directory Federation Services 2.0

Zulfiqar Ahmed

下载代码示例

作为一个开发您可能知道一些有关 Windows 标识基础 (WIF)，以前称为 “ Geneva 框架，” 它提供功能强大的 API 对索赔启用您的应用程序和创建自定义安全令牌服务。 或许您少熟悉是 Active Directory 联盟服务版本 2.0 (AD FS 2.0），最初的代码命名 “ Geneva 服务器，” 这是企业就绪联盟和单个-登录 (SSO) 解决方案。 AD FS 2.0 是从演变而来的 AD FS 1.0，并支持活动 （WS 信任） 和被动 (WS 联合身份验证和 SAML 2.0) 方案。

此文章中我可以启动与 AD FS 2.0 的概述，然后提供深入了解如何开发人员可以使用其标识解决方案中的 AD FS 2.0。 重点是 AD FS 2.0，基于 Beta 2 版的令牌颁发功能。 您可以看到从 的 图 1，此令牌颁发只有一小段 AD FS 2.0，但它是一个特定向联盟标识方向移动的.net 开发人员感兴趣。 体系结构上，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） 作为其身份存储和轻型目录访问协议 (LDAP)、 SQL 或自定义存储使用 Active Directory，作为属性存储的。 在 AD FS 2.0 STS 可以颁发给调用方使用包括 WS 信任的各种协议的安全令牌 WS 联合身份验证和安全断言标记语言 (SAML) 2.0。 AD FS 2.0 STS 还支持格式 SAML 1.1 和 SAML 2.0 令牌格式。

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 站点或 Web 服务） 的应用程序的表示形式和包含所有与安全相关信息，如加密证书，声称转换规则，依此类推。

璁剧疆依赖方

设置新的依赖方通过 AD FS 2.0 很容易。 您可以通过在 AD 中的策略节点中访问添加依赖方向导 FS 2.0 管理控制台。 一次，您或您的系统管理员需要那里在向导中 的 图 3 所示的选择数据源页中指定适当的数据源。


图 3 选择数据源页的添加依赖的部件向导

前两个选项使您可以自动配置依赖方使用联盟元数据。 如果在网络上或本地文件中，您有权访问依赖方已经联盟元数据，选择这两个选项之一，因为它们是不太容易出错，它们自动完成整个过程和它们自动更新如果在将来更改的依赖方的任何详细信息。 这些选项是主要通过 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 一个令牌

有两个选项用于使用 WCF AD FS 2.0 STS 进行交互：

  • 显式获得作为 WS 信任客户端令牌
  • 配置 WCF 客户端，以便在基础结构隐式获取令牌为调用的一部分

在显式选项 WSTrustClient 类提供一个 STS 从一个简单和直接 API 来请求令牌使用 WS 信任协议，如下所示。

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 身份验证令牌。 可以看到，显式模式中您有权访问原始的标记使用可以在以后调用服务。 渚嬪智能客户端应用程序中您可能在应用程序启动或登录名时获取不同的服务的标记、 令牌缓存中保存它们，然后它们使用在应用程序的整个生存期内，调用不同的后端服务。 此外，在方案中许多服务居住在同一个逻辑安全边界共享相同的证书中可以使用显式模式来获取单个令牌，调用所有这些服务时使用它。

 在通常有权访问依赖方已经私钥的测试环境中您可以使用下面的代码从返回的令牌中提取 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 令牌包含配置为此特定的依赖方的声明。 回头 图 4 ，它显示了此依赖方已经输出令牌返回单个属性已配置的方式。 您可以编辑要在输出中包括更多的索赔依赖方已经配置，您应该看到所有这些反映在此处。 您还可以使用索赔策略语言直接以定义丰富的转换和筛选逻辑。

WSTrustClient API 和新的 WSTrust 绑定属于 WIF，以便为前面的代码，工作，WIF 必须安装在客户端上。 您还可以直接向显式获得了令牌，但简单性使用 WCF API 和使用 WIF 优惠的易用性可以采取关闭待办事项列表的一项任务。

在 的 图 5 中的该代码在 IssuedSecurityTokenProvider WCF 等效于 WSTrustClient 并请求您的名义令牌时通常使用 wsFederationBinding 的。 因为它 ’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 代理使用它来调用服务基础结构，将为您提取新令牌。 显然，这是在某些方案中的多余。 在 的 图 6 中代码配置为要求令牌从 AD FS 2.0 虚构 EmployeeService。

图 6 的 Using 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>
映射 AD FS 2.0 WCF 的概念

AD FS 2.0 的核心责任是颁发给经过身份验证的用户的令牌。 用户可以使用不同的身份验证机制 （如 Windows 身份验证） 进行身份验证。 通过选择管理控制台中的终结点节点，您可以看到所有支持的身份验证机制。

为终结点节点内的列标题，您注意到两个熟悉 WCF 安全性概念：

  • 身份验证类型是 AD FS 2.0 等效的 WCF clientCredentialType 术语。
  • 安全模式选项有传输、 消息或混合。 混合是等效的 WCF 已经 TransportWithMessageCredentials AD FS 2.0。

使用不同的终结点公开的这两个值的不同组合，然后选择在您的身份验证需要基于某个特定的终结点。 渚嬪如果希望使用用户名/密码进行身份验证可以选择清除密码身份验证终结点。

对于返回到地址、 绑定和协定 （ABC） 中 WCF，映射这些概念的 AD FS 2.0 STS 获取以下等效项：

  • 地址 = AD FS 2.0 基址 + 终结点已经 URL 路径
  • 绑定 = 端点已经安全性模式 + 身份验证类型
  • 合同 = 标准的 WS 信任协议

与其他 STS 的 AD FS 2.0 进行联盟

除了创建依赖方，您可以建立 AD FS 2.0 和自定义的 STS 或另一种 AD FS 2.0 之间的信任关系。 渚嬪如果已经有对用户进行身份验证并颁发令牌的 STS，您可以只需将其添加为 AD FS 2.0，将接受从该 STS 颁发的令牌内受信任的身份提供程序。

璁剧疆一个标识提供程序

璁剧疆 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，在于它隐藏的中间标记的所有复杂性与获取然后发送作为身份验证令牌 R STS 到一个中间令牌 IP STS 透明地交谈。

的 图 9 中代码使用 wsFederationHttpBinding 启用 WCF 客户端在隐式地获得作为服务调用的一部分的令牌。

请注意，当 /IssuedTokenMixedSymmetricBasic256 终结点与交谈时我使用一个 customBinding。 因为它试图建立与此 AD 不兼容一个安全会话标准 wsFederationHttpBinding doesn’t 此处工作 FS 2.0 终结点。 若要联盟 WCF 客户端与 AD FS 2.0，具有使用 WIF 带有一个 customBinding 或新 WS 信任基于绑定附带之一。

图 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 联合身份验证连续线格式将与 WS 信任协议中紧密相关。 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 中它的应用程序成为受信任的依赖方 AD FS 2.0 内并且因此信任标记显示在 图 11 中的 FS 2.0 安装颁发的 AD FS 2.0。 应用程序用来执行的分析、 等等提取索赔的令牌的所有粗 lifting WIF。 标识信息提供给应用程序使用标准 IIdentity/IPrincipal 抽象化。

AD FS 2.0 中的分布式身份验证是比直接的身份验证更灵活，它提供了一些主要优点：

  • 因此身份验证机制 （渚嬪从用户名以 Kerberos） 更改不会影响应用程序，从该应用 externalized 身份验证。
  • 基于索赔的模型的灵活性可直接而不是应用程序从不同来源检索该信息本身提供 （作为标记的一部分） 应用到所有必需的信息。

WIF 的 Beta 2 发布引入新的项目模板可以很容易地 externalize 的 STS 的应用程序已经身份验证逻辑。 作为此书写的这些模板是仅在 C# 中可用。


图 11 分布式 AD FS 2.0 中的身份验证

externalizing 的验证逻辑

若要 externalize 的应用程序已经身份验证逻辑，使用新建网站 Microsoft Visual Studio 对话框。 选择 WIF 与创建标准的 ASP.NET Web 站点，预先配置的识别声明的网站模板。

启动联盟实用工具的向导显示在 图 12 中，用鼠标右键单击解决方案资源管理器中的网站节点并从菜单中选择修改 STS 参考。


图 12 的 联盟实用工具

为使本示例让我们选择 “ 使用现有 STS ” 选项，然后在 STS 作为指定 AD FS 2.0。 该向导需要自动执行所有必需的配置的元数据文档的 URL。 元数据文档 URL 是 AD FS 2.0 内终结点可用。

联盟元数据包含签名证书、 提供索赔和令牌颁发 URL STS 等基本信息。 对于此信息使工具来自动执行一个 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 将标记发送到依赖方使用 WS 联合身份验证协议中。 内部依赖方在 WIF 本身必须了解 WS 联合身份验证协议的处理这些令牌。

现在，当试图浏览到该应用程序时您将自动重定向到 AD FS 2.0 进行身份验证，您可以在其中选择身份验证方法要使用：Windows 集成身份验证、 证书身份验证或用户名/密码表单。

一旦身份验证会成功，您 — 一起使用由 AD FS 2.0 颁发令牌 — 将被重定向回发到应用程序。 WIF 处理此令牌，并使最终的身份的声明窗体） 中可用于应用程序使用标准的 ASP.NET 机制 (渚嬪 Page.User)。

基于浏览器的联盟

通过添加其他受信任的身份提供程序，您可以扩展到联盟方案基本外部的身份验证方案。 标识提供程序选项是身份验证过程中所示。

您可以进行身份验证与 AD FS 2.0 或另一个受信任的身份提供程序。 如果选择了不同的标识提供程序您将被重定向到该标识提供程序和，在成功的身份验证时转回 AD FS 将然后验证基于由受信任的身份提供程序颁发令牌的 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。