geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joris Melchior <jmelch...@pivotal.io>
Subject Re: Certificate Based Authorization
Date Mon, 02 Dec 2019 18:42:47 GMT
+1

On Mon, Dec 2, 2019 at 12:26 PM Jacob Barrett <jbarrett@pivotal.io> wrote:

> +1
>
> > On Dec 2, 2019, at 6:47 AM, Jens Deppe <jensdeppe@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.kevo@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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message