Different Service behaviors per endpoint
Asked Answered
F

1

8

The situation

We are implementing different sort of security on some WCF service. ClientCertificate, UserName & Password and Anonymous.

We have 2 ServiceBehaviorConfigurations, one for httpBinding and one for wsHttpBinding. (We have custom authorization policies for claim based security) As a requirement we need different endpoints for each service. 3 endpoints with httpBinding and 1 with wsHttpBinding.

Example for one service:

  • basicHttpBinding : Anonymous
  • basicHttpBinding : UserNameAndPassword
  • basicHttpBinding : BasicSsl
  • wsHttpBinding : BasicSsl

Note: we are working on .NET 3.5

The Problem

Part 1: We cannot specify the same service twice, once with the http service configuration and once with the wsHttp service configuration.

Part 2: We cannot specify service behaviors on an endpoint. (Throws and exception, No endpoint behavior was found... Service behaviors cant be set to endpoint behaviours)

The Config

For part 1:

<services>
  <service name="Namespace.MyService" behaviorConfiguration="securityBehavior">
   <endpoint address="http://server:94/MyService.svc/Anonymous" contract="Namespace.IMyService" binding="basicHttpBinding" bindingConfiguration="Anonymous">
    </endpoint> 
    <endpoint address="http://server:94/MyService.svc/UserNameAndPassword" contract="Namespace.IMyService" binding="basicHttpBinding" bindingConfiguration="UserNameAndPassword">
    </endpoint>
    <endpoint address="https://server/MyService.svc/BasicSsl" contract="Namespace.IMyService" binding="basicHttpBinding" bindingConfiguration="BasicSecured">
    </endpoint>
  </service>
  <service name="Namespace.MyService" behaviorConfiguration="wsHttpCertificateBehavior">
    <endpoint address="https://server/MyService.svc/ClientCert" contract="Namespace.IMyService" binding="wsHttpBinding" bindingConfiguration="ClientCert"/>
  </service>
</services>

Service Behavior configuration:

<serviceBehaviors>
<behavior name="securityBehavior">
  <serviceAuthorization serviceAuthorizationManagerType="Namespace.AdamAuthorizationManager,Assembly">
    <authorizationPolicies>
      <add policyType="Namespace.AdamAuthorizationManager,Assembly" />
    </authorizationPolicies>
  </serviceAuthorization>
</behavior>
<behavior name="wsHttpCertificateBehavior">
  <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true"/>
  <serviceAuthorization serviceAuthorizationManagerType="Namespace.AdamAuthorizationManager,Assembly">
    <authorizationPolicies>
      <add policyType="Namespace.AdamAuthorizationManager,Assembly" />
    </authorizationPolicies>
  </serviceAuthorization>
  <serviceCredentials>
    <clientCertificate>
      <authentication certificateValidationMode="PeerOrChainTrust" revocationMode="NoCheck"/>
    </clientCertificate>
    <serviceCertificate findValue="CN=CertSubject"/>
  </serviceCredentials>
</behavior>

How can we specify a different service behaviour on the WsHttpBinding endpoint? Or how can we apply our authorization policy in a different way for wsHttpBinding then basicHttpBinding. We would use endpoint behavior but we can't specify our authorization policy on an endpoint behavior

Felisafelise answered 6/9, 2012 at 7:6 Comment(0)
T
2

Authorization is a service level responsibility. You can’t vary it by endpoint.

At a high level you should:

  1. Define the endpoints bindings to use the different security configurations that you need (which you did)
  2. Create a custom ClaimsAuthenticationManager to assign claims based on the different identities that the different bindings will present.

Conceptually the ClaimsAuthenticationManager acts as an “in service STS” adding claims based on the varying credentials. From there you do claims based authorization in your service.

I’m not aware of any configurable authorization managers that will do want you want, so you’ll have to write your own (if you prove me wrong, please post what you find).

Implementing the ClaimsAuthenticationManager requires Windows Identity Framework. Below is a summary of a .NET 4.0 implementation that I used (this might be easier in 4.5). I apologize that the code doesn’t compile and isn’t complete, but I don’t have to time to scrub everything for a public post. This should point you in the right direction though.

Inherit from Microsoft.IdentityModel.Claims.ClaimsAuthenticationManager and implement Authenticate(). It should look something like this:

namespace MyWCF.ClaimsInjection
{
    public class ClaimsAuthenticationManager : Microsoft.IdentityModel.Claims.ClaimsAuthenticationManager
    {
        public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal)
        {
            if (incomingPrincipal == null)
            {
                throw new ArgumentNullException("incomingPrincipal", "ClaimInjectionClaimsAuthenticationManager requires a principal.");
            }

            IClaimsPrincipal resultPrincipal = base.Authenticate(resourceName, incomingPrincipal);
            foreach (IIdentity identity in resultPrincipal.Identities)
            {
                if (identity is ClaimsIdentity)
                {
                    // Add claims based on client cert here…
                    Claim identityClaim = ((ClaimsIdentity)identity).Claims.First(c => c.ClaimType == ClaimTypes.Thumbprint);
                    ((ClaimsIdentity)identity).Claims.Add(new Claim("MyType", "Myvalue"));
                }
                else if (identity is WindowsClaimsIdentity)
                {
                    // Add claims based on window group or account here…
                }

                // continue checking different identity types...
            }
            return resultPrincipal;
        }
    }
}

Now just install the custom manager (only including the interesting parts):

<configuration>
  <configSections>
    <section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  </configSections>

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="serviceBehavior">
          <federatedServiceHostConfiguration />
        </behavior>
      </serviceBehaviors>
    </behaviors>

    <extensions>
      <behaviorExtensions>
        <add name="federatedServiceHostConfiguration" type="Microsoft.IdentityModel.Configuration.ConfigureServiceHostBehaviorExtensionElement, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      </behaviorExtensions>
    </extensions>
  </system.serviceModel>

  <microsoft.identityModel>
    <service>
      <claimsAuthenticationManager type="MyWCF.ClaimsAuthenticationManager, MyWCF"/>
    </service>
  </microsoft.identityModel>
</configuration>
Tully answered 6/9, 2012 at 18:50 Comment(2)
We don't have problems with the ClaimsAuthenticationManager we have our own implementation. This part works, using httpBinding. But we struggle to combine wsHttpBinding and BasicHttpBinding. I'll look deeper into it tomorrow, and keep you posted.Felisafelise
In that case just apply your ClaimsAuthenticationManager once as a service behavior and make sure it can handle both wsHttp and BasicHttp presented identities in the same Authenticate() implementation... and you should be done.Tully

© 2022 - 2024 — McMap. All rights reserved.