Hi Anthony and all,
I have been working with Mario on this feature. Let me first answer the
questions:
1) Multi-user authentication will not be supported when using this new
kind of SecurityManager implementation.
2) The idea was to use only CN for principal, and ignore SAN (this would
be documented). But we could as you suggested forward both, or even
whole certificate, and let the user to decide which one to use.
According to RFC 6125
<https://tools.ietf.org/html/rfc6125#section-6.4.4>, SAN is not
replacement for CN but they complement each other.
In order to completely remove the need for username/password, it is
required that we implement this new kind of authorization on *all* geode
interfaces/components (cluster, gateway, web, jmx, locator, server). The
reason why we didn't have any progress is because we faced major
obstacle during development when we tried to retrieve clients
certificate from RMI connections (e.g. jmx connections). It seems there
are no easy/nice way to retrieve it, and what we came up so far is
following:
1) We have found some possible "hack solution" that could be implemented
and it is described in the following paper
(http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.224.2915&rep=rep1&type=pdf).
We have started to work on the prototype that will implement this solution.
2) Second idea is that client reads CN (principal) from certificate and
sends it towards server in a same way as Username/Password is sent now
over RMI connections. The downside of this solution is that server
doesn't verify the originator identity, that is, will not compare
received principal with one received within the client certificate. With
this solution, client's that uses certificates signed by geode trusted
Certificate Authority and with lower authorization privileges, can
"hack" client implementation and send principal with higher ( then which
was given to them with a certificate) authorization privileges over RMI
connection, since that principal will not compared with one received in
the certificate.
We would be really grateful if community would give us feedback if any
of this is acceptable? Any new solution proposal or hint would be really
appreciated. We have already sent a question to @dev@geode regarding
this issue: https://www.mail-archive.com/dev@geode.apache.org/msg24083.html
BRs,
Jakov
On 16. 06. 2020. 19:36, Anthony Baker wrote:
Hi Mario, just curious if you’ve made any progress on this as of yet. I have a
few questions:
1) What is the implication for multi-user auth? Would this just become a no-op
for this kind of SecurityManager implementation? See [1][2].
2) I’m not sure that the CN is sufficiently general. What if I want to use the
SAN for the Principal? Can we forward the entire certificate to the the
authenticate [3] callback?
Anthony
[1]
https://geode.apache.org/docs/guide/19/basic_config/the_cache/managing_a_multiuser_cache.html
[2]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientCache.html#createAuthenticatedView-java.util.Properties-
[3]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html#authenticate-java.util.Properties-
On Dec 6, 2019, at 9:06 AM, Jens Deppe (Pivotal)
<jde...@pivotal.io<mailto:jde...@pivotal.io>> wrote:
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
<mario.k...@est.tech<mailto:mario.k...@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 <u...@apache.com>
Poslano: 2. prosinca 2019. 20:10
Prima: dev@geode.apache.org <dev@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
