Approach to authorizing users and X.509 certificates

Question

I have a system where I'm using X.509 certificates to authenticate the client to the server. The certificate is sent to an HSM to be signed. When it is returned it is used as part of a TLS connection. Once the connection is established, I need to authorize the user i.e. what actions they are permitted to perform against the server.

Can I use X.509 certificates and logic on the server? If so, what field / content would I populate on the certificate and what logic would be necessary on the server?

Answer 1

Client certificates generally use the common name field or the subject alternative name field to identify the client. When the client presents the client certificate, your server will check that certificate signature is valid, and that the signature was made by a trusted CA, and that the client is in possession of the private key corresponding to the public key in the certificate. All of this happens as part of the TLS negotiation. If all of the above are true, then your server can authenticate the user in the common name field or the subject alternative name field of the certificate.

As far as which actions the user is allowed to take once the user is authenticated - these privileges should be stored in your database for each user, and your application logic should query the database to determine which privileges the user has, once the user is authenticated.

Related: Client certificate common name? Subject alternative name?

Answer 2

So you're looking for a way to carry either a role name, or a list of permitted actions inside a TLS client certificate. I can see why you want to do that: so everything is self-contained in the cert and specified at cert issuance time, so authorization can be enforced, even for example by offline components that have no database access. Neat idea!

This is the kind of thing that X.509v3 Extensions are made for. Unfortunately, none of the extensions defined in RFC 5280 4.2.1. Standard Extensions do what you want.

I did a bit a searching; I'm not aware of other RFCs defining an authorization extension. The Microsoft CA X.509v3 Extensions page also doesn't give anything useful. The openssl extensions page also doesn't an authorization extension, but openssl seems to have a mechanism for providing arbitrary extensions, so maybe you could encode your data there?

So in theory you could carry authorization metadata in a v3 extension, but I'm not aware of a standardized extension for doing this, so you're probably looking at defining a custom extension (which is possible, but a bit annoying). Sorry for only giving a half-answer.