Distributed Grant Management Using MongoDBAuthorizationGrant

MongoDB supports multiple authentication mechanisms, including the default one SCRAM, LDAP, Kerberos, and x.509 Certificate Authentication.

In the X.509 system, which will be the main point of this blog post, an organization can identify its entities using a pair of certificates and private keys signed and trusted by some Certificate Authority (CA).

This model is well-known in the industry, and it’s quite popular for delegating authentication to 3rd party services. The other, similar way of delegating authentication is LDAP, which is also part of the same X.500 standard group called directory services.

While authentication works fine for MongoDB – and in general for every database system – the problem with authorization remains. A MongoDB cluster still needs to obtain information about resources to which a given user has access. Roles help a lot here, but in a zero-trust model, the practice requires having information duplicated: authentication data is stored in LDAP, X.509, or any other system, and authorization models residing in MongoDB.

And here, a cool feature of X.509 and… an undocumented feature of MongoDB comes into play.

An X.509 certificate is de facto a serialized object. It uses Abstract Syntax Notation One (ASN.1), which is a standard interface description language for defining data structures that can be serialized and deserialized in a cross-platform way. It is broadly used in cryptography.

A sample deserialized certificate looks like below:

The main advantage of the above is that almost any piece of information can be stored inside a certificate. As the Certificate Authority needs to sign it, a user that’s presenting the certificate can’t modify it. That makes it secure. It also allows storing authorization information inside it.

How to Use It?

1) Let’s Start with Preparing the Certificate Authority

2) Let’s Create a Server Certificate

OpenSSL Configuration:

3) Let’s Create a Client Certificate

The above configuration will use MongoDBAuthorizationGrant OID 1.3.6.1.4.1.34601.2.1.1 and will grant the user that’s presenting the certificate two roles: backup for database admin and readAnyDatabase for database admin.

It’s important to remember that a client x.509 certificate’s subject, which contains the Distinguished Name (DN), must differ from that of a Member x.509 Certificate. Also, at least one of the Organization (O), Organizational Unit (OU), or Domain Component (DC) attributes in the client certificate must differ from those in the net.tls.clusterFile and net.tls.certificateKeyFile server certificates.

Moreover, a client certificate must contain the following fields:

• keyUsage = digitalSignature
• extendedKeyUsage = clientAuth

If the above requirements are not met, MongoDB will refuse any client x509 authentication with an error:

Let’s continue generating the request and signing the certificate:

4) Let’s Try it Out

At this stage MongoDB should allow authentication and authorization using the previously generated certificates:

It works without adding a single user!

Conclusion

• MongoDB allows embedding grants in an x.509 certificate file.
• It’s useful especially in cloud environments because it moves the authorization layer out of MongoDB.
• The certificates can be reused for different clusters.
• It forces using PKI, which is much more secure than just passwords.

Percona Distribution for MongoDB is a freely available MongoDB database alternative, giving you a single solution that combines the best and most important enterprise components from the open source community, designed and tested to work together.

Download Percona Distribution for MongoDB Today!