Re: Refactor to Restore Redundancy Command for 1.13?

[Joris Melchior]

Yes, +1 on this change.

Joris

From: Mark Hanson 
Sent: June 15, 2020 16:30
To: dev@geode.apache.org 
Subject: Re: Refactor to Restore Redundancy Command for 1.13?

To be clear the code for 1.13 using the Restore Redundancy Command in GFSH is 
fine as it stands. We are refactoring to add the REST API version.

Are people still good with that?

Thanks,
Mark

On 6/15/20, 1:28 PM, "Kirk Lund"  wrote:

+1 for getting the change into 1.13

On Mon, Jun 15, 2020 at 1:25 PM Owen Nichols  wrote:

> +1 for getting it right the first time
>
>
> ---
> Sent from Workspace ONE 
Boxer
>
> On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson 
> wrote:
> Hi All,
>
> So we are working on refactoring the Restore Redundancy gfsh command code
> and we have made a change to a class that is getting serialized. We are
> curious if this is something we could maybe get into 1.13 ( the first
> release of this command? Or should we just make our
> serialization/deserialization work for 2 versions?
>
> Thanks,
> Mark
>

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 lower the level of s

Re: Refactor to Restore Redundancy Command for 1.13?

[Dave Barnes]

If I understand correctly that the refactored version has already been
checked in and tested on `develop`, then we have enough approvals to add
this to 1.13.
Go ahead, Mark.

On Tue, Jun 16, 2020 at 8:45 AM Joris Melchior  wrote:

> Yes, +1 on this change.
>
> Joris
> 
> From: Mark Hanson 
> Sent: June 15, 2020 16:30
> To: dev@geode.apache.org 
> Subject: Re: Refactor to Restore Redundancy Command for 1.13?
>
> To be clear the code for 1.13 using the Restore Redundancy Command in GFSH
> is fine as it stands. We are refactoring to add the REST API version.
>
> Are people still good with that?
>
> Thanks,
> Mark
>
> On 6/15/20, 1:28 PM, "Kirk Lund"  wrote:
>
> +1 for getting the change into 1.13
>
> On Mon, Jun 15, 2020 at 1:25 PM Owen Nichols 
> wrote:
>
> > +1 for getting it right the first time
> >
> >
> > ---
> > Sent from Workspace ONE Boxer<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=02%7C01%7Cjmelchior%40vmware.com%7C9d6cf31bdd97492b191808d8116ae982%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637278498191299129&sdata=7pw0D4Xl2AYwFj%2BLn7apALTVw%2B5nZaVDP6Vkz0Nl4HU%3D&reserved=0
> >
> >
> > On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson 
> > wrote:
> > Hi All,
> >
> > So we are working on refactoring the Restore Redundancy gfsh command
> code
> > and we have made a change to a class that is getting serialized. We
> are
> > curious if this is something we could maybe get into 1.13 ( the first
> > release of this command? Or should we just make our
> > serialization/deserialization work for 2 versions?
> >
> > Thanks,
> > Mark
> >
>
>

Re: Refactor to Restore Redundancy Command for 1.13?

[Mark Hanson]

Hi Dave, 

So this PR is actually awaiting some reviews before it will be put on develop.

Thanks,
Mark

On 6/16/20, 2:07 PM, "Dave Barnes"  wrote:

If I understand correctly that the refactored version has already been
checked in and tested on `develop`, then we have enough approvals to add
this to 1.13.
Go ahead, Mark.

On Tue, Jun 16, 2020 at 8:45 AM Joris Melchior  wrote:

> Yes, +1 on this change.
>
> Joris
> 
> From: Mark Hanson 
> Sent: June 15, 2020 16:30
> To: dev@geode.apache.org 
> Subject: Re: Refactor to Restore Redundancy Command for 1.13?
>
> To be clear the code for 1.13 using the Restore Redundancy Command in GFSH
> is fine as it stands. We are refactoring to add the REST API version.
>
> Are people still good with that?
>
> Thanks,
> Mark
>
> On 6/15/20, 1:28 PM, "Kirk Lund"  wrote:
>
> +1 for getting the change into 1.13
>
> On Mon, Jun 15, 2020 at 1:25 PM Owen Nichols 
> wrote:
>
> > +1 for getting it right the first time
> >
> >
> > ---
> > Sent from Workspace ONE Boxer<
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=02%7C01%7Chansonm%40vmware.com%7C774b45ee83db4e6a5a5a08d812394116%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279384406586799&sdata=vcdgVzwoT7OO7%2BJJC1s6U8VVO2lpg0rYFCLSMHR9Kq4%3D&reserved=0
> >
> >
> > On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson 
> > wrote:
> > Hi All,
> >
> > So we are working on refactoring the Restore Redundancy gfsh command
> code
> > and we have made a change to a class that is getting serialized. We
> are
> > curious if this is something we could maybe get into 1.13 ( the 
first
> > release of this command? Or should we just make our
> > serialization/deserialization work for 2 versions?
> >
> > Thanks,
> > Mark
> >
>
>

Re: Refactor to Restore Redundancy Command for 1.13?

[Dave Barnes]

Thanks for clarifying, Mark. Let's wait for all the approvals and test
results before back-porting to 1.13.


On Tue, Jun 16, 2020 at 2:16 PM Mark Hanson  wrote:

> Hi Dave,
>
> So this PR is actually awaiting some reviews before it will be put on
> develop.
>
> Thanks,
> Mark
>
> On 6/16/20, 2:07 PM, "Dave Barnes"  wrote:
>
> If I understand correctly that the refactored version has already been
> checked in and tested on `develop`, then we have enough approvals to
> add
> this to 1.13.
> Go ahead, Mark.
>
> On Tue, Jun 16, 2020 at 8:45 AM Joris Melchior 
> wrote:
>
> > Yes, +1 on this change.
> >
> > Joris
> > 
> > From: Mark Hanson 
> > Sent: June 15, 2020 16:30
> > To: dev@geode.apache.org 
> > Subject: Re: Refactor to Restore Redundancy Command for 1.13?
> >
> > To be clear the code for 1.13 using the Restore Redundancy Command
> in GFSH
> > is fine as it stands. We are refactoring to add the REST API version.
> >
> > Are people still good with that?
> >
> > Thanks,
> > Mark
> >
> > On 6/15/20, 1:28 PM, "Kirk Lund"  wrote:
> >
> > +1 for getting the change into 1.13
> >
> > On Mon, Jun 15, 2020 at 1:25 PM Owen Nichols <
> onich...@vmware.com>
> > wrote:
> >
> > > +1 for getting it right the first time
> > >
> > >
> > > ---
> > > Sent from Workspace ONE Boxer<
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=02%7C01%7Chansonm%40vmware.com%7C774b45ee83db4e6a5a5a08d812394116%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279384406586799&sdata=vcdgVzwoT7OO7%2BJJC1s6U8VVO2lpg0rYFCLSMHR9Kq4%3D&reserved=0
> > >
> > >
> > > On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson <
> hans...@vmware.com>
> > > wrote:
> > > Hi All,
> > >
> > > So we are working on refactoring the Restore Redundancy gfsh
> command
> > code
> > > and we have made a change to a class that is getting
> serialized. We
> > are
> > > curious if this is something we could maybe get into 1.13 (
> the first
> > > release of this command? Or should we just make our
> > > serialization/deserialization work for 2 versions?
> > >
> > > Thanks,
> > > Mark
> > >
> >
> >
>
>

[PROPOSAL] backport PR #5250 to support/1.13

[Bruce Schuchardt]

This PR has been merged to develop.  It fixes a problem with the previous 
commit for GEODE-8144 that caused performance degradation when TLS is enabled 
between servers.  I have run perf tests and verified that it fixes the problem.

It’s a small change that makes a big difference…
https://github.com/apache/geode/pull/5250

RE: [PROPOSAL] backport PR #5250 to support/1.13

[Dick Cavender]

+1

-Original Message-
From: Bruce Schuchardt  
Sent: Tuesday, June 16, 2020 3:24 PM
To: dev@geode.apache.org
Subject: [PROPOSAL] backport PR #5250 to support/1.13

This PR has been merged to develop.  It fixes a problem with the previous 
commit for GEODE-8144 that caused performance degradation when TLS is enabled 
between servers.  I have run perf tests and verified that it fixes the problem.

It’s a small change that makes a big difference…
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5250&data=02%7C01%7Cdickc%40vmware.com%7C3c5cb9fbd9274b032b8508d8124403ad%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279430617900387&sdata=eT22ksaNTZIFI%2F14NrTkauiiDclGug37g0SEX7Uklek%3D&reserved=0

Re: [PROPOSAL] backport PR #5250 to support/1.13

[Jianxia Chen]

+1

On Tue, Jun 16, 2020 at 3:24 PM Bruce Schuchardt  wrote:

> This PR has been merged to develop.  It fixes a problem with the previous
> commit for GEODE-8144 that caused performance degradation when TLS is
> enabled between servers.  I have run perf tests and verified that it fixes
> the problem.
>
> It’s a small change that makes a big difference…
> https://github.com/apache/geode/pull/5250
>
>

Re: [PROPOSAL] backport PR #5250 to support/1.13

[Owen Nichols]

+1

On 6/16/20, 3:54 PM, "Jianxia Chen"  wrote:

+1

On Tue, Jun 16, 2020 at 3:24 PM Bruce Schuchardt  wrote:

> This PR has been merged to develop.  It fixes a problem with the previous
> commit for GEODE-8144 that caused performance degradation when TLS is
> enabled between servers.  I have run perf tests and verified that it fixes
> the problem.
>
> It’s a small change that makes a big difference…
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5250&data=02%7C01%7Conichols%40vmware.com%7Ce2ec5e282bb240a6406d08d812484504%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279448892893348&sdata=1qOm9MNcOb0JbWE8PTtLJEicYXbO8QglFaPk18VhRss%3D&reserved=0
>
>