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.
leastprivilege.com 
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.
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.
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.
Sorry – there are a myriad of possible reasons for this.
Reblogged this on http://www.leastprivilege.com and commented:
An old posts. But since I am writing about AuthenticationHandler..this is still relevant!
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
yep – see here
https://github.com/thinktecture/Thinktecture.IdentityModel.45/tree/master/Samples/Web%20API%20Security/Clients/BasicAuthAndClientCert
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!
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.
Okay, I did wonder if I’d just need to do something like that. Thanks again!