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> 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 > > > > >