overview scenarios accessing claims windows authentication username authentication

I use this configuration:

<system.serviceModel>

  <services>

    <service name=“Common.ClaimsService“>

      <endpoint address=“certificatemixed“

                binding=“netHttpBinding“

                contract=“Common.IClaimsService“ />

    </service>

  </services>

 

  <bindings>

    <netHttpBinding>

      <binding>

        <security mode=“TransportWithMessageCredential“>

          <message clientCredentialType=“Certificate“ />

        </security>

      </binding>

    </netHttpBinding>

  </bindings>

</system.serviceModel>

 

On the client you need to pass in the certificate you want to use for authentication (the X509 class is from Thinktecture.IdentityModel):

var factory = new ChannelFactory<IClaimsService>(“*”);

factory.Credentials.ClientCertificate.Certificate =

    X509.

    CurrentUser.

    My.

    SubjectDistinguishedName.

    Find(“CN=Client”).

    First();

 

var proxy = factory.CreateChannel();

var id = proxy.GetIdentity();

 

By default the WCF service will do a chain validation check against the client cert, and if the issuer is in your trusted CA store, this will just work. You can also check against a fixed list of allowed client certificates, by doing a search if the client cert is in the Trusted People store:

<behaviors>

  <serviceBehaviors>

    <behavior>

 

      <serviceCredentials>

        <clientCertificate>

          <authentication certificateValidationMode=“PeerTrust“ />

        </clientCertificate>

      </serviceCredentials>

         

    </behavior>

  </serviceBehaviors>

</behaviors>

 

If you want more fine-grained control over certificate validation, you need to write your own validator logic. The following code snippet does a chain validation first, and then checks for a specific CA:

public class CertificateValidator : X509CertificateValidator

{

    public override void Validate(X509Certificate2 certificate)

    {

        if (new X509Chain().Build(certificate))

        {

            if (certificate.Issuer == “CN=CorpCA”)

            {

                return;

            }

        }

 

        throw new SecurityTokenValidationException();

    }

}

 

Your wire up that validator in the serviceCredentials/clientCertificate config.

With this approach Thread.CurrentPrincipal will be empty, and you have to use the ServiceSecurityContext to get to the client’s identity, which will be in this case a combination of the certificate subject name and thumbprint. Don’t like that.

Enabling “WIF” Mode
In WIF mode you have access to the client certificate details via claims on Thread.Currentprincipal. But there are also different approaches when it comes to validation.

<behaviors>

  <serviceBehaviors>

    <behavior>

      <serviceCredentials useIdentityConfiguration=“true“ />

    </behavior>

  </serviceBehaviors>

</behaviors>

By default, WCF will use the configured issuer name registry to find out, if you want to accept the client certificate. WCF ships with one built-in registry, called the ConfigurationBasedIssuerNameRegistry. A issuer name registry gets to see the certificate of the issuer of the client cert and can either accept the issuer, or reject it, e.g.:

<system.identityModel>

  <identityConfiguration>

    <issuerNameRegistry type=“….ConfigurationBasedIssuerNameRegistry, … “>

      <trustedIssuers>

        <add name=“CorpCA“

             thumbprint=“B772884B7DC7F367CDBA0C9D7CE8348946876E96“ />

      </trustedIssuers>

    </issuerNameRegistry>

  </identityConfiguration>

</system.identityModel>

 

This is how you would implement the above custom validation scenario (here or in Thinktecture.IdentityModel you can find a registry called TestIssuerNameRegistry which allows all issuers and return the subject distinguished name of the issuer).

You can write your own registry if you need that level of control. When you also need access to the details of the client cert (not just the issuer), you can still use a certificate validator (or specifically disable it). This time you have to register the validator in the <system.identityModel /> section:

<system.identityModel>

  <identityConfiguration>

 

    <certificateValidation certificateValidationMode=“Custom“>

      <certificateValidator type=“Type, Assembly“/>

    </certificateValidation>

 

  </identityConfiguration>

</system.identityModel>

 

And after you told WCF to also populate Thread.CurrentPrincipal, everything works now as expected:

<behaviors>

  <serviceBehaviors>

    <behavior>

      <serviceCredentials useIdentityConfiguration=“true“ />

      <serviceAuthorization principalPermissionMode=“Always“ />

    </behavior>

  </serviceBehaviors>

</behaviors>