How to mix WIF and non-WIF endpoints in a single WCF <service>?

A WIF-based WCF service needs to call method FederatedServiceCredentials.Conf开发者_JS百科igureServiceHost(), 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>?

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.

You may be confusing the use of WIF with using an STS. They are not related.

WS2007FederationHttpBinding will cause the WCF endpoint to expect an issued token (from an STS). WS2007HttpBinding or NetTcpBinding can require a Windows token.

You can use WIF to handle both, in fact it is WITH WIF that you are able to have a service behavior that supports two different token formats more effectively.

The issued token endpoint will rely on the configuration for the saml11/saml2 security token handler in WIF config to process the token and the trusted issuer section to establish trust of that token. The windows endpoint will rely on one of the windows security token handlers to process the windows token.

Both will funnel through the WIF service authz manager but will hydrate claims for windows or for your issued token. you can use the claimsAUthenticationManager to transform those claims prior to reaching the claimsauthorizationmanager to authorize access.

THere are lots of ways to skin this cat but that is definitely possible.