Question

A WIF-based WCF service needs to call method FederatedServiceCredentials.ConfigureServiceHost(), or put the equivalent element <federatedServiceHostConfiguration> in the web.config file, to work. This is a setting on the service level, in other words it applies for all endpoints.

According to the method documentation, the ServiceHostBase instance is modified in several WIF-specific ways. For example, the authorization is replaced by a WIF-based authorization class.

Now I’d like to have a single <service> (inside <system.serviceModel><services>) with multiple <endpoint>s, where one endpoint is WIF-based, and the others are using plain Windows authentication.

Update. In response to an answer below, let me explain why we want to mix WIF and non-WIF endpoints. If we only use WIF, then each of our customers needs an STS, like AD FS. Setting this up is not difficult, but it is a hurdle, especially if they just want to test drive our software. So what we do is install in a mode where Windows integrated authentication is used (for our web services, and also for our front end), and then later they can switch to a mode where AD FS is used.

So basically we want to be able to install without AD FS to lower the barrier to entry of our application.

To do this, the <service> needs a <federatedServiceHostConfiguration>. However — and here is my problem — this affects also the non-WIF endpoints for that same service: for example, they suddenly use the WIF authorization manager (an instance of class ClaimsAuthorizationManager).

So my question is: what is the recommended way to mix WIF and non-WIF endpoints in a single WCF <service>?

Answer 1

I don’t think you can. In your situation though, you should only have the one WIF endpoint have leave the multiple credential support to the STS.

You can put multiple endpoints on your STS to handle different types of authentication. One for Windows, one for username/password for example.

I did a code camp oz session last year that demonstrated this. The source is attached to my blog post at http://www.neovolve.com/post/2010/11/21/CodeCampOz-Not-a-WIF-of-federation.aspx. Have a look at the web.config in 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>

This is how I configured the STS to support multiple types of authentication. The RP should only deal in claims, not claims|WindowsIdentity. It is the STS’s responsibility to convert a particular type of authentication into a set of claims that the RP will use.