Re: Odg: Certificate Based Authorization

[Jacob Barrett]

On Jun 23, 2020, at 8:08 AM, Jakov Varenina 
mailto:jakov.varen...@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 
mailto:jabarr...@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

[Jakov Varenina]

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  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  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 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  
wrote:

>>
>>
>>
>>>
>>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina 
mailto:jakov.varen...@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 

Re: Odg: Certificate Based Authorization

[Jacob Barrett]

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  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 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  wrote:
>>
>>
>>
>>>
>>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina 
>>> mailto:jakov.varen...@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%3Dpdfdata=02%7C01%7Cjabarrett%40vmware.com%7Cb850f9bde4674352e4a908d8149b3ad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637282004231487337sdata=SbJiZKJxsJ3lTmKFVFIPRNzVO2tmc4w817Asbra5lR4%3Dreserved=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

[Jinmei Liao]

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  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 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  wrote:
>
>
>
>>
>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina 
>> mailto:jakov.varen...@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%3Dpdfdata=02%7C01%7Cjiliao%40vmware.com%7C047d1b26112f4948b0ab08d8149b3ad3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637282004228769823sdata=6fB1iM1Dk%2BJ%2B8oCHankNhd4%2FSd5EwKcxZlex%2BTcUg8U%3Dreserved=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

[Jacob Barrett]

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 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  wrote:
> 
> 
> 
>> 
>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina 
>> mailto:jakov.varen...@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%3Dpdfdata=02%7C01%7Cjabarrett%40vmware.com%7C0540782b5fd04f118ec108d8147c9e31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637281872755348036sdata=AXxPkuFmrfvqQLKWQSTf9w0%2B7tFjsQ8%2FuATCNAx3hT8%3Dreserved=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

[Jacob Barrett]

On Jun 19, 2020, at 12:20 PM, Anthony Baker 
mailto:bak...@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

[Anthony Baker]

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 
mailto:jabarr...@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

[Jacob Barrett]

> 
> On Jun 18, 2020, at 4:24 AM, Jakov Varenina 
> mailto:jakov.varen...@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%3Dpdfdata=02%7C01%7Cjabarrett%40vmware.com%7Ce9d45eb604334359a29708d814745030%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637281837084459652sdata=vWYeTsTQmP6RyIz5xEIdsVRjnXii%2Buk02TwLXuyGBEo%3Dreserved=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

[Jacob Barrett]

On Jun 18, 2020, at 4:24 AM, Jakov Varenina 
mailto:jakov.varen...@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 
,
 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%3Dpdfdata=02%7C01%7Cjabarrett%40vmware.com%7Cca7271e56ce84e558a2a08d8137a41be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280763124731300sdata=%2Fdk70AwZSk0YVPDrYESvMq2u6cV%2Bn4ia3i3BQGpgE2c%3Dreserved=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 

Re: Odg: Certificate Based Authorization

[Jakov Varenina]

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=rep1=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) 
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 
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 
Poslano: 2. prosinca 2019. 20:10
Prima: 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 

Re: Odg: Certificate Based Authorization

[Anthony Baker]

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) 
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 
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 
Poslano: 2. prosinca 2019. 20:10
Prima: 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 low

Odg: Certificate based authorization - CN authorization in jmx

[Mario Kevo]

Hi all,

Kindly reminder on this question.
Thanks in an advance!

BR,
Mario

Šalje: Mario Kevo 
Poslano: 22. svibnja 2020. 13:56
Prima: dev@geode.apache.org 
Predmet: Certificate based authorization - CN authorization in jmx

Hi geode-dev,

We are working on implementing a new feature regarding to this 
RFC<https://cwiki.apache.org/confluence/display/GEODE/Certificate+Based+Authorization>.

The main idea is to combine the TLS and access control features, but to use the 
certificate subject common name for access control authentication/authorization 
instead of user credentials.
We need to get client certificate on the server side to extract common name 
from it. The problem is that gfsh client connects towards to jmx using RMI TCP 
connections. We have tried many things to get client certificate from 
established RMI Connection but unfortunately without success.

Did anyone have the similar problem and able to extract certificate from RMI 
Connection after TLS handshake has been completed?

BR,
Mario

Certificate based authorization - CN authorization in jmx

[Mario Kevo]

Hi geode-dev,

We are working on implementing a new feature regarding to this 
RFC<https://cwiki.apache.org/confluence/display/GEODE/Certificate+Based+Authorization>.

The main idea is to combine the TLS and access control features, but to use the 
certificate subject common name for access control authentication/authorization 
instead of user credentials.
We need to get client certificate on the server side to extract common name 
from it. The problem is that gfsh client connects towards to jmx using RMI TCP 
connections. We have tried many things to get client certificate from 
established RMI Connection but unfortunately without success.

Did anyone have the similar problem and able to extract certificate from RMI 
Connection after TLS handshake has been completed?

BR,
Mario

Odg: Odg: Certificate Based Authorization

[Mario Kevo]

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 
Poslano: 6. prosinca 2019. 18:06
Prima: dev@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  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 
> Poslano: 2. prosinca 2019. 20:10
> Prima: 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
> lay

Re: Odg: Certificate Based Authorization

[Jens Deppe]

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  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 
> Poslano: 2. prosinca 2019. 20:10
> Prima: 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
> >
> >
>

Odg: Certificate Based Authorization

[Mario Kevo]

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 
Poslano: 2. prosinca 2019. 20:10
Prima: 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
>
>

Re: Certificate Based Authorization

[Udo Kohlmeyer]

+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: Certificate Based Authorization

[Joris Melchior]

+1

On Mon, Dec 2, 2019 at 12:26 PM Jacob Barrett  wrote:

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

Re: Certificate Based Authorization

[Jacob Barrett]

+1

> On Dec 2, 2019, at 6:47 AM, Jens Deppe  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  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: Certificate Based Authorization

[Jens Deppe]

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

Certificate Based Authorization

[Mario Kevo]

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