To be Reviewed By:  January 16, 2020

Authors:  Mario Kevo

Status: Draft | Discussion | Development | 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?

  • No labels

4 Comments

  1. Bill Burcham

    So do I have this right: you are proposing that Geode support using the common name from a (client's) digital certificate, as the principal used for authorization decisions?

    It took me longer to understand the proposal because the term "principal" is never used here.

    This threw me off:

    certificate subject common name for access control authentication/authorization instead of user credentials

    Because I don't think it makes any sense to say that common name would be used for authentication. Also certificates are credentials so I don't think it makes sense to say they are an alternative to credentials. When you mention "credentials" at the end of that line are you referring specifically to the result of AuthInitialize.getCredentials() ? If so that makes sense.

    Please correct me if I'm wrong but after a bit of research, it seems like what you're really after is that you want Geode to use the common name from the client's cert as the principal for authorization purposes (only when TLS and TLS client authentication are turned on).

  2. Mario Kevo

    Hi Bill Burcham , sorry for a late response.

    Yes. Proposal is  that Geode support using the common name from a (client's) digital certificate, as the principal used for authorization decisions.

    Yes, “credentials” refers to the result of AuthInitialize.getCredentials.

    And for the last thing : Yes, correct. Authentication is included because this would make the implementation pretty easy (at least for client connections). At the place where geode remembers the client credentials we could remember the certificate common name instead. After that everything is left to the already existing access control mechanisms.

  3. Jinmei Liao

    So, basically you are proposing instead of using username/password to log in, if SSL is enabled, we can use the common name in the certificate as the username (no password is needed since we already validate the certificate). 

    What if there is a common name in the certificate and there is also a username/password combination, what wins? 

    The benefit of this seems to be that you don't need to implement the "authenticate" method in the security manager, only the "authorize", but remember SSL can be enabled for certain channels, say your client/server is SSL enabled, but not jmx, then for any jmx connection, you still need to provide username/password, so your security manager would still need that "authenticate" method. I don't see much benefit in this feature though.

    1. Mario Kevo

      Hi Jinmei Liao , As we agreed on dev list user should set ssl-enabled-components=all if want to use this feature.

      Also new flag will be added to specify if this feature is enabled or not. In case user provide both certificate and username/password combination, and feature is enabled it will use CN from certificate and ignore username/password.

      We have a problem with getting CN on JMX so I send mail to dev list for some help if anyone know this part and maybe have a similar problem.