如何将WIF和非WIF端点混合在一个WCF <service>中？

Question

基于WIF的WCF服务需要调用方法FederatedServiceCredentials.ConfigureServiceHost()，或者将等效的放在web.config文件中才能工作。这是一个服务级别的设置，换句话说，它适用于所有端点。

根据方法文档，ServiceHostBase实例是以几种特定于WIF的方式进行修改的。例如，授权被基于WIF的授权类替换.

现在，我希望有一个<service> (在<system.serviceModel><services>中)具有多个<endpoint>，其中一个端点是基于WIF的，而其他端点则使用普通的<endpoint>身份验证。

更新。作为对下面的答案的回应，让我解释一下为什么我们要混合WIF和非WIF端点。如果我们只使用WIF，那么我们的每个客户都需要一个STS，比如AD。设置这个并不困难，但这是一个障碍，特别是如果他们只想测试驱动我们的软件。因此，我们所做的是安装在一个使用Windows集成身份验证的模式中(对于我们的web服务，以及我们的前端)，然后它们可以切换到使用AD FS的模式。 因此，我们基本上希望能够在没有AD的情况下安装，以降低进入应用程序的门槛。

为此，<service>需要一个<federatedServiceHostConfiguration>。但是--这是我的问题--这也影响到同一服务的非WIF端点:例如，它们突然使用WIF授权管理器(ClaimsAuthorizationManager的一个实例)。

因此，我的问题是:在单个WCF <service>中混合WIF和非WIF端点的推荐方法是什么？

Answer 1

我觉得你做不到。但是，在您的情况下，您应该只有一个WIF端点将多个凭据支持留给STS。

您可以在STS上放置多个端点来处理不同类型的身份验证。例如，一个用于Windows，另一个用于用户名/密码。

去年我做了一个代码营oz会议，展示了这一点。这个消息来源附在我在http://www.neovolve.com/post/2010/11/21/CodeCampOz-Not-a-WIF-of-federation.aspx的博客上。查看一下web.config中的NotAWif Demo\4 - Identity Delegation\NotAWif.DelegationSTS。

<system.serviceModel>
  <services>
    <service behaviorConfiguration="ServiceBehavior"
                    name="Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract">

      <endpoint address="UserName/IWSTrust13"
                        binding="ws2007HttpBinding"
                        bindingConfiguration="ws2007HttpBindingUserNameConfiguration"
                        contract="Microsoft.IdentityModel.Protocols.WSTrust.IWSTrust13SyncContract" />

      <endpoint address="Windows/IWSTrust13"
                binding="ws2007HttpBinding"
                bindingConfiguration="ws2007HttpBindingWindowsConfiguration"
                contract="Microsoft.IdentityModel.Protocols.WSTrust.IWSTrust13SyncContract" />

      <endpoint address="mex"
                        binding="mexHttpsBinding"
                        contract="IMetadataExchange" />
      <host>
        <baseAddresses>
          <add baseAddress="https://localhost/NotAWif.DelegationSTS/Service.svc" />
        </baseAddresses>
      </host>
    </service>
  </services>
  <bindings>
    <ws2007HttpBinding>
      <binding name="ws2007HttpBindingUserNameConfiguration">
        <security mode="TransportWithMessageCredential">
          <transport clientCredentialType="None">
            <extendedProtectionPolicy policyEnforcement="Never" />
          </transport>
          <message clientCredentialType="UserName"
                                establishSecurityContext="false" />
        </security>
      </binding>
      <binding name="ws2007HttpBindingWindowsConfiguration">
        <security mode="TransportWithMessageCredential">
          <transport clientCredentialType="None">
            <extendedProtectionPolicy policyEnforcement="Never" />
          </transport>
          <message clientCredentialType="Windows"
                                establishSecurityContext="false" />
        </security>
      </binding>
    </ws2007HttpBinding>
  </bindings>
  <behaviors>
    <serviceBehaviors>
      <behavior name="ServiceBehavior">
        <serviceMetadata httpGetEnabled="true" />
        <serviceDebug includeExceptionDetailInFaults="false" />
        <serviceCredentials>
          <serviceCertificate findValue="DefaultApplicationCertificate"
                                          x509FindType="FindBySubjectName" />
        </serviceCredentials>
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

这就是我如何配置STS以支持多种类型的身份验证。RP只应处理索赔，而不应处理索赔WindowsIdentity。STS的责任是将特定类型的身份验证转换为RP将使用的一组声明。

Answer 2

您可能混淆了WIF的使用和STS的使用。他们没有亲属关系。

WS2007FederationHttpBinding将导致WCF端点期望得到一个已发出的令牌(来自STS)。WS2007HttpBinding或NetTcpBinding可能需要一个Windows令牌。

您可以使用WIF来处理这两种情况，实际上，只有使用WIF，您才能有更有效地支持两种不同令牌格式的服务行为。

发出的令牌端点将依赖于WIF配置中saml2 11/saml2 2安全令牌处理程序的配置来处理令牌和可信颁发者部分来建立该令牌的信任。windows端点将依赖于windows安全令牌处理程序之一来处理windows令牌。

这两种方法都会通过WIF服务授权管理器(WIF服务授权管理器)，但都会为windows或您发布的令牌提供更多的索赔。您可以在到达claimsauthorizationmanager以授权访问之前使用claimsAUthenticationManager来转换这些声明。

THere有很多方法可以剥去这只猫的皮，但这是绝对有可能的。