Certificate Based Authorization

To be Reviewed By:  January 16, 2020

Authors:  Mario Kevo

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: N/A

Problem

Geode doesn’t provide a TLS based authorization mechanism. Users who want secure communication and authorization have to enable both TLS and access control, which means handling (generating, sharing, storing, rotating) both the certificates and credentials.

Anti-Goals

Solution

                The idea is to combine the TLS and access control features, but to use the certificate subject common name for access control authentication/authorization instead of user credentials. User credentials wouldn’t be necessary.

                Configuration:

                ssl-enabled-components=all

                ssl-keystore=mykeystore.jks

                ssl-keystore-password=password

                ssl-truststore=mytruststore.jks

                ssl-truststore-password=password

                security-manager=my.security.manager

security-peer-auth-init=

security-client-auth-init=

For peer2peer communication, if the auth-init parameters are set to null we can conclude that the user wants authorization based on the certificate common name, since no way for getting the credentials if provided. For client connections, we could presume that certificate based authorization should be used if both features are enabled, but the client cache properties don’t provide credentials (security-username/security-password).

Behaviour:

While receiving a peer or client connection, once we get past the TLS layer, we read and remember the peer certificate common name used for that connection. We save it similarly to how we save the received credentials currently. From that point on we can use the already existing access control flow and  logic for authorization.

For multi user authentication, we would still need to keep the use of credentials, so that would have no impact besides the ClientCache creation.

Changes and Additions to Public Interfaces

If you are proposing to add or modify public interfaces, those changes should be outlined here in detail.

Performance Impact

None.

Backwards Compatibility and Upgrade Path

No upgrade or backwards compatibility issues.

Prior Art

What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?