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