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