You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Anthony Baker <ba...@vmware.com> on 2020/06/16 17:36:50 UTC
Re: Odg: Certificate Based Authorization
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) <jd...@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 <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
Re: Odg: Certificate Based Authorization
Posted by Jacob Barrett <ja...@vmware.com>.
On Jun 19, 2020, at 12:20 PM, Anthony Baker <ba...@vmware.com>> wrote:
That’s fine, I just want to understand what happens when I use this API:
createdAuthenticatedView(…)
Does it throw an exception? Silently work but not switch to the new user?
I would expect that first off we document the usage of certificate based authentication is generally mutually exclusive to the use of multiuser authentication. Secondly, I would expect the SecurityManager should reject any authentication request that it receives if it can’t authenticate the given credentials it was sent so the behavior at the client should reflect that those credentials were denied.
It would however be possible to mix both application and user authentication in a SecurityManger in theory you could have multi user authentication, just not with certificates for the user (can be done with client/server protocol changes). An operation performed on an authenticated view would have both the application’s certificate credentials and user credentials sent to the SecurityManager. That implementation can do whatever it wants with them.
-Jake
Re: Odg: Certificate Based Authorization
Posted by Anthony Baker <ba...@vmware.com>.
That’s fine, I just want to understand what happens when I use this API:
createdAuthenticatedView(…)
Does it throw an exception? Silently work but not switch to the new user?
Thanks,
Anthony
On Jun 19, 2020, at 10:14 AM, Jacob Barrett <ja...@vmware.com>> wrote:
1) Multi-user authentication will not be supported when using this new kind of SecurityManager implementation.
I agree here. What we are implementing is application/service level authentication. Using certs from the applications connection is not viable for multi-user authentication. A method similar to option 2 below would need to be implemented for such a thing. (See comments below on option 2 issues)
Re: Odg: Certificate Based Authorization
Posted by Jacob Barrett <ja...@vmware.com>.
On Jun 23, 2020, at 8:08 AM, Jakov Varenina <ja...@est.tech>> wrote:
We haven't gone far with the implementation of the solution described in the research paper. So it is a great that you have found alternative and better solution, but it seems that the attachment with patch is missing from you mail.
Not sure what happened. I just pushed the branch to my fork so here is a link to the diff.
https://github.com/apache/geode/compare/develop...pivotal-jbarrett:wip/certificate-auth
Could you please just clarify a bit more your opinion on this below?
> On Jun 19, 2020, at 2:53 PM, Jacob Barrett <ja...@vmware.com>> wrote:
> ... Personally I would be inclined to leave RMI out of the solution
initially. Second I would use this private variable to compete the
support in OpenJDK..
If I correctly understood and we leave RMI out of the solution that would mean one of the following scenarios:
1) Geode would have to use existing username/password authentication and authorization feature just for RMI connections, and the new kind of certificate auth for all other interfaces. This way user will still have to handle usernames/passwords which we want to get rid of, and also this would complicate a little bit more implementation of SecurityManager interface (user would have to deal with both certificates and username/passwords).
2) If geode doesn't use username/password feature and the certificate based auth is enabled, then it will have to reject all RMI connections, since the clients initiating those RMI connections cannot be properly authenticated and authorized on the server side.
Yes, you would either support both username/password based auth for interactive user logins and certificate based for non-interactive application/service logins or prevent fail all RMI authentication rendering gfsh/pulse over RMI ineffective.
At this point, given the ease of getting RMI working with the branch I shared I think I would now be inclined to include RMI in the initial solution.
-Jake
Re: Odg: Certificate Based Authorization
Posted by Jakov Varenina <ja...@est.tech>.
Hi Jake and all,
Great findings and analysis Jake! Thank you very much for you effort!
We haven't gone far with the implementation of the solution described in
the research paper. So it is a great that you have found alternative and
better solution, but it seems that the attachment with patch is missing
from you mail.
Also, we agree with your points that it is better to read certificate on
server side and forward it as a whole to the SecurityManager
authenticate, since it adds more benefit and flexibility to the users
than just having CN and SAN.
Could you please just clarify a bit more your opinion on this below?
> On Jun 19, 2020, at 2:53 PM, Jacob Barrett <ja...@vmware.com> wrote:
> ... Personally I would be inclined to leave RMI out of the solution
initially. Second I would use this private variable to compete the
support in OpenJDK..
If I correctly understood and we leave RMI out of the solution that
would mean one of the following scenarios:
1) Geode would have to use existing username/password authentication and
authorization feature just for RMI connections, and the new kind of
certificate auth for all other interfaces. This way user will still have
to handle usernames/passwords which we want to get rid of, and also this
would complicate a little bit more implementation of SecurityManager
interface (user would have to deal with both certificates and
username/passwords).
2) If geode doesn't use username/password feature and the certificate
based auth is enabled, then it will have to reject all RMI connections,
since the clients initiating those RMI connections cannot be properly
authenticated and authorized on the server side.
BRs/Jakov
On 22. 06. 2020. 23:11, Jacob Barrett wrote:
> I went on a little journey to see if it was possible and it looks
> promising. I was able to get access to the SSLSocket and thus the
> SSLContext.
>
> Proof of concept patch attached.
>
>
>
> > On Jun 19, 2020, at 2:53 PM, Jacob Barrett <ja...@vmware.com> wrote:
> >
> > So I can see why this research paper was so bleak about the options
> in trying to get the SSL certificate for the current connection being
> serviced. As they discovered the accept loop in OpenJDK’s (and older
> Oracle implementations) immediately fires the RMI operation to a
> thread pool after connected. This is after SSLSocket would have
> would’ve done the handshake and been passed to any of our validation
> callbacks so stashing anything in a thread local storage is dead.
> >
> > Good news is deep in the sun.rmi.transport.tcp.TCPTransport there is
> a ThreadLocal<ConnectionHandler> that has the socket used to establish
> the connection and this thread local is set before each invocation of
> an RMI operation. The bad news is that it's private on an internal
> class. I think this is where the age of the research is in our favor.
> Back when I think it was writing we didn’t have OpenJDK. We had
> Oracle, IBM, and a few others. Now with everything pretty much
> converging on OpenJDK I don’t believe it as as nasty to go poke at
> this internal using reflection. I think it is less dirty then their
> nasty trick of utilizing the IPv6 address as a unique identifier in a
> custom Socket.
> >
> > Once we have the SSLSocket for this connection then we are golden.
> From there you have public API access to the SSLSession.
> >
> > Looking at the OpenJDK source this class has largely been unchanged
> since its initial import into the repo in 2007. Most importantly the
> private member in question has been and its sill available in all
> versions of OpenJDK. Sure this limits us to OpenJDK support for
> certificate based authentication by SSL handshake via RMI but in Geode
> that’s really only gfsh. This is a really small surface area. With the
> focus being on converting gfsh activities into REST APIs this surface
> area is shrinking. Personally I would be inclined to leave RMI out of
> the solution initially. Second I would use this private variable to
> compete the support in OpenJDK.
> >
> > -Jake
> >
> >
> >> On Jun 19, 2020, at 11:14 AM, Jacob Barrett <ja...@vmware.com>
> wrote:
> >>
> >>
> >>
> >>>
> >>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina
> <ja...@est.tech>> wrote:
> >>>
> >>> 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
> (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjabarrett%40vmware.com%7Cb850f9bde4674352e4a908d8149b3ad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637282004231487337&sdata=SbJiZKJxsJ3lTmKFVFIPRNzVO2tmc4w817Asbra5lR4%3D&reserved=0).
> We have started to work on the prototype that will implement this
> solution.
> >>
> >> Wow, that is a hack. Have you found any implementation of this
> solution. There doesn’t appear to be a repository listed. There also
> doesn’t appear to be a publish date on this document. The most recent
> references are from 2010. I wonder if things are better now. I am
> going to poke at the Java source code a bit and report back.
> >>
> >> Would your needs be dependent on Java 8? If we found a solution
> that only worked say with java 12, would that work?
> >>
> >> -Jake
> >>
> >
>
Re: Odg: Certificate Based Authorization
Posted by Jacob Barrett <ja...@vmware.com>.
I went on a little journey to see if it was possible and it looks promising. I was able to get access to the SSLSocket and thus the SSLContext.
Proof of concept patch attached.
> On Jun 19, 2020, at 2:53 PM, Jacob Barrett <ja...@vmware.com> wrote:
>
> So I can see why this research paper was so bleak about the options in trying to get the SSL certificate for the current connection being serviced. As they discovered the accept loop in OpenJDK’s (and older Oracle implementations) immediately fires the RMI operation to a thread pool after connected. This is after SSLSocket would have would’ve done the handshake and been passed to any of our validation callbacks so stashing anything in a thread local storage is dead.
>
> Good news is deep in the sun.rmi.transport.tcp.TCPTransport there is a ThreadLocal<ConnectionHandler> that has the socket used to establish the connection and this thread local is set before each invocation of an RMI operation. The bad news is that it's private on an internal class. I think this is where the age of the research is in our favor. Back when I think it was writing we didn’t have OpenJDK. We had Oracle, IBM, and a few others. Now with everything pretty much converging on OpenJDK I don’t believe it as as nasty to go poke at this internal using reflection. I think it is less dirty then their nasty trick of utilizing the IPv6 address as a unique identifier in a custom Socket.
>
> Once we have the SSLSocket for this connection then we are golden. From there you have public API access to the SSLSession.
>
> Looking at the OpenJDK source this class has largely been unchanged since its initial import into the repo in 2007. Most importantly the private member in question has been and its sill available in all versions of OpenJDK. Sure this limits us to OpenJDK support for certificate based authentication by SSL handshake via RMI but in Geode that’s really only gfsh. This is a really small surface area. With the focus being on converting gfsh activities into REST APIs this surface area is shrinking. Personally I would be inclined to leave RMI out of the solution initially. Second I would use this private variable to compete the support in OpenJDK.
>
> -Jake
>
>
>> On Jun 19, 2020, at 11:14 AM, Jacob Barrett <ja...@vmware.com> wrote:
>>
>>
>>
>>>
>>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina <ja...@est.tech>> wrote:
>>>
>>> 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 (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjabarrett%40vmware.com%7Cb850f9bde4674352e4a908d8149b3ad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637282004231487337&sdata=SbJiZKJxsJ3lTmKFVFIPRNzVO2tmc4w817Asbra5lR4%3D&reserved=0). We have started to work on the prototype that will implement this solution.
>>
>> Wow, that is a hack. Have you found any implementation of this solution. There doesn’t appear to be a repository listed. There also doesn’t appear to be a publish date on this document. The most recent references are from 2010. I wonder if things are better now. I am going to poke at the Java source code a bit and report back.
>>
>> Would your needs be dependent on Java 8? If we found a solution that only worked say with java 12, would that work?
>>
>> -Jake
>>
>
Re: Odg: Certificate Based Authorization
Posted by Jinmei Liao <ji...@vmware.com>.
In the old management team, we have been considering the idea of getting rid of jmx connection in gfsh and only using http connection mechanism.
On Jun 19, 2020 2:53 PM, Jacob Barrett <ja...@vmware.com> wrote:
So I can see why this research paper was so bleak about the options in trying to get the SSL certificate for the current connection being serviced. As they discovered the accept loop in OpenJDK’s (and older Oracle implementations) immediately fires the RMI operation to a thread pool after connected. This is after SSLSocket would have would’ve done the handshake and been passed to any of our validation callbacks so stashing anything in a thread local storage is dead.
Good news is deep in the sun.rmi.transport.tcp.TCPTransport there is a ThreadLocal<ConnectionHandler> that has the socket used to establish the connection and this thread local is set before each invocation of an RMI operation. The bad news is that it's private on an internal class. I think this is where the age of the research is in our favor. Back when I think it was writing we didn’t have OpenJDK. We had Oracle, IBM, and a few others. Now with everything pretty much converging on OpenJDK I don’t believe it as as nasty to go poke at this internal using reflection. I think it is less dirty then their nasty trick of utilizing the IPv6 address as a unique identifier in a custom Socket.
Once we have the SSLSocket for this connection then we are golden. From there you have public API access to the SSLSession.
Looking at the OpenJDK source this class has largely been unchanged since its initial import into the repo in 2007. Most importantly the private member in question has been and its sill available in all versions of OpenJDK. Sure this limits us to OpenJDK support for certificate based authentication by SSL handshake via RMI but in Geode that’s really only gfsh. This is a really small surface area. With the focus being on converting gfsh activities into REST APIs this surface area is shrinking. Personally I would be inclined to leave RMI out of the solution initially. Second I would use this private variable to compete the support in OpenJDK.
-Jake
> On Jun 19, 2020, at 11:14 AM, Jacob Barrett <ja...@vmware.com> wrote:
>
>
>
>>
>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina <ja...@est.tech>> wrote:
>>
>> 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 (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjiliao%40vmware.com%7C047d1b26112f4948b0ab08d8149b3ad3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637282004228769823&sdata=6fB1iM1Dk%2BJ%2B8oCHankNhd4%2FSd5EwKcxZlex%2BTcUg8U%3D&reserved=0). We have started to work on the prototype that will implement this solution.
>
> Wow, that is a hack. Have you found any implementation of this solution. There doesn’t appear to be a repository listed. There also doesn’t appear to be a publish date on this document. The most recent references are from 2010. I wonder if things are better now. I am going to poke at the Java source code a bit and report back.
>
> Would your needs be dependent on Java 8? If we found a solution that only worked say with java 12, would that work?
>
> -Jake
>
Re: Odg: Certificate Based Authorization
Posted by Jacob Barrett <ja...@vmware.com>.
So I can see why this research paper was so bleak about the options in trying to get the SSL certificate for the current connection being serviced. As they discovered the accept loop in OpenJDK’s (and older Oracle implementations) immediately fires the RMI operation to a thread pool after connected. This is after SSLSocket would have would’ve done the handshake and been passed to any of our validation callbacks so stashing anything in a thread local storage is dead.
Good news is deep in the sun.rmi.transport.tcp.TCPTransport there is a ThreadLocal<ConnectionHandler> that has the socket used to establish the connection and this thread local is set before each invocation of an RMI operation. The bad news is that it's private on an internal class. I think this is where the age of the research is in our favor. Back when I think it was writing we didn’t have OpenJDK. We had Oracle, IBM, and a few others. Now with everything pretty much converging on OpenJDK I don’t believe it as as nasty to go poke at this internal using reflection. I think it is less dirty then their nasty trick of utilizing the IPv6 address as a unique identifier in a custom Socket.
Once we have the SSLSocket for this connection then we are golden. From there you have public API access to the SSLSession.
Looking at the OpenJDK source this class has largely been unchanged since its initial import into the repo in 2007. Most importantly the private member in question has been and its sill available in all versions of OpenJDK. Sure this limits us to OpenJDK support for certificate based authentication by SSL handshake via RMI but in Geode that’s really only gfsh. This is a really small surface area. With the focus being on converting gfsh activities into REST APIs this surface area is shrinking. Personally I would be inclined to leave RMI out of the solution initially. Second I would use this private variable to compete the support in OpenJDK.
-Jake
> On Jun 19, 2020, at 11:14 AM, Jacob Barrett <ja...@vmware.com> wrote:
>
>
>
>>
>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina <ja...@est.tech>> wrote:
>>
>> 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 (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjabarrett%40vmware.com%7C0540782b5fd04f118ec108d8147c9e31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637281872755348036&sdata=AXxPkuFmrfvqQLKWQSTf9w0%2B7tFjsQ8%2FuATCNAx3hT8%3D&reserved=0). We have started to work on the prototype that will implement this solution.
>
> Wow, that is a hack. Have you found any implementation of this solution. There doesn’t appear to be a repository listed. There also doesn’t appear to be a publish date on this document. The most recent references are from 2010. I wonder if things are better now. I am going to poke at the Java source code a bit and report back.
>
> Would your needs be dependent on Java 8? If we found a solution that only worked say with java 12, would that work?
>
> -Jake
>
Re: Odg: Certificate Based Authorization
Posted by Jacob Barrett <ja...@vmware.com>.
>
> On Jun 18, 2020, at 4:24 AM, Jakov Varenina <ja...@est.tech>> wrote:
>
> 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 (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjabarrett%40vmware.com%7Ce9d45eb604334359a29708d814745030%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637281837084459652&sdata=vWYeTsTQmP6RyIz5xEIdsVRjnXii%2Buk02TwLXuyGBEo%3D&reserved=0). We have started to work on the prototype that will implement this solution.
Wow, that is a hack. Have you found any implementation of this solution. There doesn’t appear to be a repository listed. There also doesn’t appear to be a publish date on this document. The most recent references are from 2010. I wonder if things are better now. I am going to poke at the Java source code a bit and report back.
Would your needs be dependent on Java 8? If we found a solution that only worked say with java 12, would that work?
-Jake
Re: Odg: Certificate Based Authorization
Posted by Jacob Barrett <ja...@vmware.com>.
On Jun 18, 2020, at 4:24 AM, Jakov Varenina <ja...@est.tech>> wrote:
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.
I agree here. What we are implementing is application/service level authentication. Using certs from the applications connection is not viable for multi-user authentication. A method similar to option 2 below would need to be implemented for such a thing. (See comments below on option 2 issues)
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6125%23section-6.4.4&data=02%7C01%7Cjabarrett%40vmware.com%7Cca7271e56ce84e558a2a08d8137a41be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280763124731300&sdata=GoHTUKN2MVyztXmIO0l22dz2c9p0W3v2l9kOOY9a4hE%3D&reserved=0>, SAN is not replacement for CN but they complement each other.
I have reservations about only forwarding the CN in the credential properties. I have been doing some research in this area I strongly feel we need to forward the entire certificate. It should also be done in a way the prevents the client from being able to forward this same key/value to the server in the authentication part of the handshake. What the SecurityMangaer is trusting is that the SSL engine did its due diligence and verified and validated the certificate. So only the SSL Engine should be able to export this “authenticated” certificate. The SecurityManager is simply trusting the third party authentication by its mean presence in the credentials, or some other out of band means. By passing the entire certificate it allows the SM implantation to use whatever portions of the certificate it wants for identity mapping. It could use the CN, something the SAN, and some extension.
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 (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjabarrett%40vmware.com%7Cca7271e56ce84e558a2a08d8137a41be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280763124731300&sdata=%2Fdk70AwZSk0YVPDrYESvMq2u6cV%2Bn4ia3i3BQGpgE2c%3D&reserved=0). We have started to work on the prototype that will implement this solution.
I want to spend some time digging into this issue with you. I just saw yesterday you all were stuck on this and haven’t had a chance to dig in. Can I sync up with you later today?
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.
As you pointed out, having the client send the certificate in the auth part of the handshake doesn’t authenticate the origin. To do this you must have a challenge. The current protocol does not have a challenge response handshake so the challenge must be pre-arranged. Like simply hashing the a password gives you the ability to replay the hash should you intercept it, same would go for the cert. Pre-arranged challenges have also their own security issues because you know some part of the message, think cracking the Enigma. A common practice would be a known challenge with salt. It solves the known message part since there is randomness at the start of the message it randomizes the output of the encryption. It doesn’t solve the playback issue that pre-arranged challenges have though. For this you need a once token of some kind. This token can be used once and only once when making a challenge. This then requires the server to remember these once tokens to avoid playback issues. Now if the server could give the client a challenge then we solve all these problems. Well now we have re-invented the SSL handshake or re-implemented our protocol to support challenge response. Obviously re-implementing SSL is silly, we should just continue using option 1 since all we want is application/service authentications right now anyway. If we do want a more robust client/server auth system that does support challenge response and many other types of authentications we should look towards SASL rather than inventing our own.
Long story short, given the immediate concerns is authenticating the application not the user we should continue on option 1 and try to find a way to export the already authenticated certificate to the SM.
-Jake
Re: Odg: Certificate Based Authorization
Posted by Jakov Varenina <ja...@est.tech>.
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) <jd...@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 <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
>
>
>
>