5

After countless hours of reading I have come to the find that mutual authentication via client certificates seemed to be a viable and appropriate solution for the following scenario.

I have a ASP.NET MVC Website, call it example.com, with an area that needs to be secured so only our partners can access it. Requiring our partners to register each of their employees is out of the question so I thought issuing a client certificate to our each of partners would be a more reasonable solution.

So my questions are this.

  1. Are client certificates the appropriate method of authenticating our partners or should we use a different authentication scheme?
  2. How can I issue/manage client certificates to our partners? Do I need to use a managed PKI like DigiCert or Verisign?
  3. If client certificates are the appropriate method how do I verify the client certificate being supplied by a partner is one our company issued and that it is still valid?

As of right now when we partner with a company an entry will be made into our database with the name of the partner, their location, ect... and they will be given a unique id.

My idea was to store the certificate serial # & thumbprint in a table with the company's unique id, is this enough info to validate a certificate? Does this seem like a reasonable solution?

matt.
  • 152
  • 6
  • 1
    I have no experience with ASP.net, but the usual method would be to create an own root certificate and have your webserver trust it. You can then sign the certificates you give to your clients with that root key. – Philipp Apr 11 '15 at 21:49
  • "Requiring our partners to register each of their employees is out of the question so I thought issuing a client certificate to our each of partners would be a more reasonable solution." - So you replace registering each employee with shipping a certificate to each employee (probably after registration)? Or do you want all employees of the same partner to share the same certificate, which would then be no different then sharing the same login? – Steffen Ullrich Apr 11 '15 at 22:19
  • Preferably one certificate per partner, installed on each machine. – matt. Apr 11 '15 at 22:25
  • 1
    A shared certificate has the same security as a shared login. – Steffen Ullrich Apr 11 '15 at 22:26
  • Okay, so what's your solution? – matt. Apr 11 '15 at 22:28
  • It depends what you need. If you want to identity different users at the partner you have to create an account for each of them, no matter if login or certificate based. If you don't care about different users and can live with the risk that employees leave the company and take login/certificate with them then you can create a account per partner. It does not matter much in this case how you protect the account, only if it is shared or not. – Steffen Ullrich Apr 11 '15 at 22:30
  • 1
    But the administrative overhead to change the account in case an employee leaves is higher with the certificate based solution, because you have to roll out somehow the new certificates to all machines instead of just telling everybody the new password of the shared account. – Steffen Ullrich Apr 11 '15 at 22:34
  • We only need to identity partners, not particular employees. Our thoughts are employees come and go, our partners will be on a more permanent basis. If we were to issue certificates to each individual the partner would then need to notify us if somebody leaves so the cert could be revoked. – matt. Apr 11 '15 at 22:34
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/22772/discussion-between-nwdev-and-steffen-ullrich). – matt. Apr 11 '15 at 22:35

1 Answers1

4

Yes, and no.

Using client certificates doesn't solve the problem, it moves the problem. Whereas before your problem is the creation, distribution, and protection of a password or other secret. And now your problem is the creation, distribution, and protection of a client certificate.

A client certificate is a lot like a password. But it has the special property that it can be validated by signatures. So if you're going to use client certs, the best way to go is to give the company a signing cert and have the company use that cert to sign certificates for all of its users. There's a certain amount of IT overhead to this idea, so it might not fly with your company.

An interesting alternative might be to use an SSO protocol, which basically means training your service to trust their login system. This can be done with off-the-shelf software, and support may already be included in the auth solution their company is using. For example most only services support OAuth 2, while Active Directory has baked-in SAML support.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • I am not set on using certificates, I thought it would be easier..how naive of me. Distributing signing certificates and letting them manage the creating and deletion of employee certs sounds interesting but so does the SAML support of AD. I believe most of our partners are all using Windows with AD, how would I authenticate with a token I didn't create though? I would much rather trust their login system and have an SSO experience. – matt. Apr 12 '15 at 16:28