+1 On Mon, Dec 2, 2019 at 12:26 PM Jacob Barrett <jbarr...@pivotal.io> wrote:
> +1 > > > On Dec 2, 2019, at 6:47 AM, Jens Deppe <jensde...@apache.org> wrote: > > > > Hi Mario, > > > > Definitely sounds like a good idea! Feel free to write up a RFC proposal > > with more details. > > > > Thanks > > --Jens > > > > On Mon, Dec 2, 2019 at 1:30 AM Mario Kevo <mario.k...@est.tech> 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 > >> > >> > > -- *Joris Melchior * CF Engineering Pivotal Toronto 416 877 5427 “Programs must be written for people to read, and only incidentally for machines to execute.” – *Hal Abelson* <https://en.wikipedia.org/wiki/Hal_Abelson>
