Hi Mario, just curious if you’ve made any progress on this as of yet. I have a few questions:
1) What is the implication for multi-user auth? Would this just become a no-op for this kind of SecurityManager implementation? See [1][2]. 2) I’m not sure that the CN is sufficiently general. What if I want to use the SAN for the Principal? Can we forward the entire certificate to the the authenticate [3] callback? Anthony [1] https://geode.apache.org/docs/guide/19/basic_config/the_cache/managing_a_multiuser_cache.html [2] https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientCache.html#createAuthenticatedView-java.util.Properties- [3] https://geode.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html#authenticate-java.util.Properties- On Dec 6, 2019, at 9:06 AM, Jens Deppe (Pivotal) <jde...@pivotal.io<mailto:jde...@pivotal.io>> wrote: Thanks for the write-up. I think it does require a bit of clarification around how the functionality is enabled. You've stated: 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). Currently, the presence of any '*auth-init' parameters, does not necessarily require setting *security-username/password* (although almost all implementations of AuthInitialize probably do use them). So this condition will not be sufficient to enable this new functionality. Although we already have so many parameters I think that having an explicit parameter, to enable this feature, will avoid any possible confusion. I'm wondering whether, for an initial deliverable, we should require *ssl-enabled-components=all*. This would not allow a mix of different forms of authentication for different endpoints. Perhaps this might simplify the implementation but would not preclude us from adding that capability in the future. --Jens On Fri, Dec 6, 2019 at 1:13 AM Mario Kevo <mario.k...@est.tech<mailto:mario.k...@est.tech>> wrote: Hi all, I wrote up a proposal for Certificate Based Authorization. Please review and comment on the below proposal. https://cwiki.apache.org/confluence/display/GEODE/Certificate+Based+Authorization BR, Mario ________________________________ Šalje: Udo Kohlmeyer <u...@apache.com> Poslano: 2. prosinca 2019. 20:10 Prima: dev@geode.apache.org <dev@geode.apache.org> Predmet: Re: Certificate Based Authorization +1 On 12/2/19 1:29 AM, Mario Kevo wrote: Hi, There is another potential functionality we would like to discuss and get some comments for. The idea is TLS certificate based authorization. Currently, if a user wants secure communication (TLS) + authorization, he needs to enable TLS and access control. The user also needs to handle both the certificates for TLS and the credentials for access control. The idea we have is to use both features: TLS and access control, but remove the need to handle the credentials (generating and securely storing the username and password). Instead of the credentials, the certificate subject DN would be used for authorization. This would of course be optional. We would leave the possibility to use these 2 features as they are right now, but would also provide a configuration option to use the features without the need for client credentials, utilizing the certificate information instead. For further clarity, here are the descriptions of how the options would work: 1. Using TLS and access control as they work right now * Certificates are prepared for TLS * A SecurityManager is prepared for access control authentication/authorization. As part of this, a file (e.g. security.json) is prepared where we define the allowed usernames, passwords and authorization rights for each username * The credentials are distributed towards clients. Here a user needs to consider secure distribution and periodical rotation of credentials. Once a client initiates a connection, we first get the TLS layer and certificate check, and right after that we perform the authentication/authorization of the user credentials. 1. TLS certificate based authorization * Certificates are prepared for TLS * A SecurityManager is prepared for access control authentication/authorization. As part of this, a file (e.g. security.json) is prepared. In this case we don’t define the authorization rights based on usernames/passwords but based on certificate subject DNs. * There is no more need to distribute or periodically rotate the credentials, since there would be none. Authorization would be based on the subject DN fetched from the certificate used for that same connection Once a client initiates a connection, and when we get past the TLS layer, at the moment where geode expects the credentials from the client connection, we just take the certificate subject DN instead and provide it to the security manager for authorization. This wouldn’t lower the level of security (we can have TLS enabled without access control already), but would provide authentication without the hassle of username and password handling. This is the basic description of the idea. There would be more things to consider, like multi user authentication, but for now we would just like to get some initial feedback. If it is considered useful, we could get into the details. BR, Mario
