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
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
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
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
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
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
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
>
> 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,
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
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 u
>> 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
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
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
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
>
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
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
+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
gt; 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 i
>>
>>
>>
>> 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 TL
r. 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 hav
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
21 matches
Mail list logo
