Support for X.509 Client Certificates in Thinktecture.IdentityModel for Web API

Another RTM feature I was waiting for is (reasonable) SSL client certificate support in Web API.

Just like all the other authentication methods, you configure client certificate support on the AuthenticationConfiguration object. The following code configures the certificate to chain validation + check for a specific issuer subject name:

config.AddClientCertificate(

    ClientCertificateMode.ChainValidationWithIssuerSubjectName,

    “CN=TestCA”);

Validation modes are:

  • Chain validation only
  • Peer validation
  • Chain validation + issuer certificate thumbprint
  • Chain validation + issuer subject name
  • Thumbprint only

On the client side, this is the necessary code to include a client certificate with the call:

var handler = new WebRequestHandler();

handler.ClientCertificates.Add(

    X509.

    CurrentUser.

    My.

    SubjectDistinguishedName.

    Find(“CN=Client”).First());

 

var client = new HttpClient(handler) { BaseAddress = _baseAddress };

                   

var response = await client.GetAsync(“identity”);

 

The code + client sample is in the github repository. Nuget will be updated soon.

This entry was posted in IdentityModel, WebAPI. Bookmark the permalink.

10 Responses to Support for X.509 Client Certificates in Thinktecture.IdentityModel for Web API

  1. Igor says:

    Hello Dominick. Thank you for your work.
    I’m trying to make examples from github working on my local developer pc, but I’ve stuck

    Here is code in AuthentificationConfig
    #region Client Certificate
    config.AddClientCertificate(ClientCertificateMode.IssuerThumbprint,
    “A1EED7897E55388FCE60FEF1A1EED81FF1CBAEC6″);
    #endregion

    here is the code in ClientCertificateClient/program.cs
    handler.ClientCertificates.Add( X509.CurrentUser.My.Thumbprint.Find”BC1A7A817081AC5A8DEDC6B3B3776E069E78DE71”).First());
    var client = new HttpClient(handler) { BaseAddress = _baseAddress };

    var response = client.GetAsync(“identity”).Result;
    response.EnsureSuccessStatusCode();
    _baseAddress – now points to webapi service from example, that has been hosted in local iis
    (via webhost)

    but, it returns not authorized exception
    I’ve tried various self-signed certificates, result is the same – nonauthorized.

    So, questions:
    1. client & server – it should be different computers, or it can be the same
    2. certificates that you use in client & server side – is there any connection between them, or they are completely independent from each other?
    3. Can they be self-signed (and non-valid)
    Thank you.

    • lou says:

      1. client & server – it should be different computers, or it can be the same
      Ans: Can be different or the same computers. IIS must be configured to accept client certificates.

      2. certificates that you use in client & server side – is there any connection between them, or they are completely independent from each other?
      Ans: No connection between the two certificates. You must register the client certificate with the idsrv and create a user account that matches the CN of the client certificate.

      3. Can they be self-signed (and non-valid)
      ans: They can be self-signed certificates

      Enable tracing on the idsrv to help narrow down any issues.

  2. Meghasyam Yedla says:

    Hello sir,
    I have worked on x509 certificates after reading your article. The following link I followed for the guidance. http://msdn.microsoft.com/en-us/magazine/cc163454.aspx. I could see the certificates in my development (local host) everything was fine. But after deploying in my web server It is showing exception the current session is not interactive. If you don’t mind could you please help me regarding this. I am using basic .Net 2.0.

  3. Reblogged this on http://www.leastprivilege.com and commented:

    An old posts. But since I am writing about AuthenticationHandler..this is still relevant!

  4. Reece Williams says:

    Hi Dominick,

    Is it possible to combine this with say Basic Authentication, so as to create a two-factor authentication mechanism? I.e. The client/user must provide both username and password (implemented by the AddBasicAuthentication) and their client certificate (implemented by the AddClientCertificate) to pass authentication?

    Apologies if I’ve missed something obvious somewhere!

    Many thanks

    Reece

      • Reece Williams says:

        Thanks for the reply.

        Again, I might be missing something here, but I can’t see how that enforces BOTH types of authentication.

        It seems to me, having traced the code through, that if either basic auth or client certificate passes, then the user becomes validated. But what I really want is to say that both have to pass for a user to be valid.

        Will I need to create my own implementation of the HttpAuthentication class to cater for this?

        Basically, I’m building a system that will need to cater for multi-factor authentication, and using basic and certificate as a proof of concept, but unless I’ve completely misunderstood it all, a multi-factor authentication should enforce validation of both/all configured handlers.

        As a general note, thanks for all the hard work you’ve put into the IdentityModel. It’s been invaluable for learning about securing the Web Api!

  5. Every authentication type produces exactly one ClaimsIdentity is successful. In other words, you could check the number of identities in the ClaimsPrincipal inside the ClaimsAuthenticationManager. No need for a custom implementation of HttpAuthentication.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s