Odg: Odg: Certificate Based Authorization

[Mario Kevo <ma...@est.tech>]

Hi,

First of all, sorry Jens, I somehow miss your last mail. 🙁

Regarding add new parameter to activate this feature to avoid confusion. It is a good option, we can go with that.
Also it will be easier to implement if we require ssl-enabled-components=all.

As end date for this RFC passed a long time ago, I will move it to next phase.
If someone has some comments or advices please feel free to add it here or on the RFC.

Thank you all,
Mario

________________________________
Šalje: Jens Deppe <jd...@pivotal.io>
Poslano: 6. prosinca 2019. 18:06
Prima: dev@geode.apache.org <de...@geode.apache.org>
Predmet: Re: Odg: Certificate Based Authorization

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 <ma...@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 <ud...@apache.com>
> Poslano: 2. prosinca 2019. 20:10
> Prima: dev@geode.apache.org <de...@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
> >
> >
>