[DISCUSSION] De/un-deprecate IndexType ENUM

[Joris Melchior]

Hi All,

Looking for feedback on the proposal to [un/de]deprecate the IndexType ENUM
on Geode.

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477

Thanks, Joris.

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

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Jacob Barrett]

> On Dec 1, 2019, at 2:40 PM, John Blum  wrote:
> 
> After some modifications to Spring Data for Apache Geode (Spring Data
> Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
> 
> While I support the modularization effort, I would make it very clear (in
> documentation) now that both geode-logging and geode-serialization are
> required on the application classpath when using Apache Geode.
> 
> Technically, I am not entirely certain about geode-serialization (yet), but
> geode-logging is strictly required to use Apache Geode.  I need to run some
> more tests.

Both are properly listed as runtime scope in the geode-core POM. Is SDG 
creating its dependencies manually or using the transitive dependencies from 
the Geode POMs?

-Jake

Proposals - Request For Comments (RFC) process

[Charlie Black]

Just as a reminder we do have a light weight process for handling changes
in "public" areas like configuration, monitoring, command line tools, etc.
So as we get close to proposing changing something for the better we might
want to make sure we are following the process to ensure we are doing the
right thing.

The Apache Geode Improvement Process.

https://cwiki.apache.org/confluence/display/GEODE/Lightweight+RFC+Process

Charlie
-- 
Charlie Black | cbl...@pivotal.io

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*

Re: IndexType deprecation question

[Joris Melchior]

Okay, that is good feedback. I lean towards un-deprecating as well. Let me
write a draft proposal for some changes so everyone can chime in and
hopefully we'll have a workable target at the end of it.

Thanks, Joris.

On Mon, Dec 2, 2019 at 1:00 PM John Blum  wrote:

> My vote would be to UNDEPRECATE the IndexType in Apache Geode.  There are
> several codepaths in SDG that use the IndexType to make certain decisions.
>
> I also think having an Enum is much more flexible than having a method per
> Index type, particularly since you can use Enum values in switch
> statements.  I do like the createXyzIndex methods (e.g. createKeyIndex) for
> common OQL Indexes, however.  I do think the createIndex for
> FUNCTIONAL/RANGE OQL Indexes should be renamed (rather, the old method
> deprecated and a new method introduced, i.e. createRangeIndex or
> createFunctionalIndex).
>
> -j
>
>
> On Mon, Dec 2, 2019 at 9:44 AM Jason Huynh  wrote:
>
> > Hi Joris,
> >
> > Just some guesses and no actual answer from me here:
> >
> > The deprecation of the index type was before HASH indexes were created,
> and
> > my guess was due to the introduction of the "new at the time" query
> service
> > apis (the javadoc:@deprecated As of 6.6.1. Check {@link QueryService}
> for
> > changes.)
> >
> > The internals still use the IndexType as you have pointed out and maybe
> the
> > deprecation was more intended for the end user (since it's not an
> internal
> > type) and perhaps it was intended to have been moved internal at some
> > point?
> >
> > There is some weirdness with the index types and actually having multiple
> > implementations for the Functional type.  Under the covers we create a
> > memory-optimized version based on the indexed expression.
> >
> > Things have changed since deprecation, so maybe it should be
> > un/de-deprecated or an alternative solution can probably be thought up...
> >
> > -Jason
> >
> >
> > On Mon, Dec 2, 2019 at 9:13 AM Joris Melchior 
> > wrote:
> >
> > > Hi Jason,
> > >
> > > At this point it is not about creating but returning the Region with an
> > > indicator in the management API without using deprecated parts. Under
> the
> > > covers the QueryService java api still uses the IndexType ENUM and had
> > > assumed that an alternative would be provided when something is marked
> as
> > > deprecated.
> > >
> > > I can of course create a new ENUM to return but prefer not to take this
> > > step before ensuring that we don't have something in place already.
> > >
> > > I'm also wondering if the deprecation should have been limited to the
> > HASH
> > > type on the IndexType ENUM instead of deprecating the complete ENUM.
> > >
> > > Thanks, Joris.
> > >
> > > On Mon, Dec 2, 2019 at 12:05 PM Jason Huynh  wrote:
> > >
> > > > Hi Joris,
> > > >
> > > > How are you creating the index?  If using the QueryService java api,
> > > there
> > > > should be createKeyIndex() and createIndex() methods.  These methods
> > > should
> > > > create the primary key index and the functional index.
> > > >
> > > > I am not sure if there is an alternative in gfsh... it might still be
> > > using
> > > > the IndexType enum or something similar.
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior <
> jmelch...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Thanks John.
> > > > >
> > > > > I'm trying to use it on the server side for the management API so
> > > > > unfortunately the Spring wrapper is not an option. Hopefully
> someone
> > > can
> > > > > provide some insight into the deprecation background once all the
> > > turkey
> > > > > and stuffing has been digested.
> > > > >
> > > > > On Fri, Nov 29, 2019 at 2:16 PM John Blum 
> wrote:
> > > > >
> > > > > > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > > > > > spring-data-geode), then there is an SDG Index enum type
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > > >
> > > > > > [1]
> > > > > > wrapping the deprecated Apache Geode Index enum type
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > > > > >
> > > > > >  [2].
> > > > > >
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > > [2]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > > > >
> > > > > >
> > > > > > On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior <
> > jmelch...@pivotal.io
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > I notice that the ENUM
> > > > > > >
> > > > > > > org.apache.geode.cache.query.IndexType has been deprecated but
> 

Re: IndexType deprecation question

[John Blum]

My vote would be to UNDEPRECATE the IndexType in Apache Geode.  There are
several codepaths in SDG that use the IndexType to make certain decisions.

I also think having an Enum is much more flexible than having a method per
Index type, particularly since you can use Enum values in switch
statements.  I do like the createXyzIndex methods (e.g. createKeyIndex) for
common OQL Indexes, however.  I do think the createIndex for
FUNCTIONAL/RANGE OQL Indexes should be renamed (rather, the old method
deprecated and a new method introduced, i.e. createRangeIndex or
createFunctionalIndex).

-j


On Mon, Dec 2, 2019 at 9:44 AM Jason Huynh  wrote:

> Hi Joris,
>
> Just some guesses and no actual answer from me here:
>
> The deprecation of the index type was before HASH indexes were created, and
> my guess was due to the introduction of the "new at the time" query service
> apis (the javadoc:@deprecated As of 6.6.1. Check {@link QueryService} for
> changes.)
>
> The internals still use the IndexType as you have pointed out and maybe the
> deprecation was more intended for the end user (since it's not an internal
> type) and perhaps it was intended to have been moved internal at some
> point?
>
> There is some weirdness with the index types and actually having multiple
> implementations for the Functional type.  Under the covers we create a
> memory-optimized version based on the indexed expression.
>
> Things have changed since deprecation, so maybe it should be
> un/de-deprecated or an alternative solution can probably be thought up...
>
> -Jason
>
>
> On Mon, Dec 2, 2019 at 9:13 AM Joris Melchior 
> wrote:
>
> > Hi Jason,
> >
> > At this point it is not about creating but returning the Region with an
> > indicator in the management API without using deprecated parts. Under the
> > covers the QueryService java api still uses the IndexType ENUM and had
> > assumed that an alternative would be provided when something is marked as
> > deprecated.
> >
> > I can of course create a new ENUM to return but prefer not to take this
> > step before ensuring that we don't have something in place already.
> >
> > I'm also wondering if the deprecation should have been limited to the
> HASH
> > type on the IndexType ENUM instead of deprecating the complete ENUM.
> >
> > Thanks, Joris.
> >
> > On Mon, Dec 2, 2019 at 12:05 PM Jason Huynh  wrote:
> >
> > > Hi Joris,
> > >
> > > How are you creating the index?  If using the QueryService java api,
> > there
> > > should be createKeyIndex() and createIndex() methods.  These methods
> > should
> > > create the primary key index and the functional index.
> > >
> > > I am not sure if there is an alternative in gfsh... it might still be
> > using
> > > the IndexType enum or something similar.
> > >
> > >
> > >
> > >
> > > On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior 
> > > wrote:
> > >
> > > > Thanks John.
> > > >
> > > > I'm trying to use it on the server side for the management API so
> > > > unfortunately the Spring wrapper is not an option. Hopefully someone
> > can
> > > > provide some insight into the deprecation background once all the
> > turkey
> > > > and stuffing has been digested.
> > > >
> > > > On Fri, Nov 29, 2019 at 2:16 PM John Blum  wrote:
> > > >
> > > > > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > > > > spring-data-geode), then there is an SDG Index enum type
> > > > > <
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > >
> > > > > [1]
> > > > > wrapping the deprecated Apache Geode Index enum type
> > > > > <
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > > > >
> > > > >  [2].
> > > > >
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > [2]
> > > > >
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > > >
> > > > >
> > > > > On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior <
> jmelch...@pivotal.io
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I notice that the ENUM
> > > > > >
> > > > > > org.apache.geode.cache.query.IndexType has been deprecated but
> > can't
> > > > > > find what to use instead of this ENUM if I wanted to use a
> > > > > > non-deprecated alternative.
> > > > > >
> > > > > > I understand that HASH indexes are no longer recommended but the
> > > other
> > > > > > types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
> > > > > > should be able to use them without using deprecated code.
> > > > > >
> > > > > > Can anyone tell me how this is accomplished?
> > > > > >
> > > > > > Thanks, Joris.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > *Joris Melchior *
> > > > > > CF Engineering
> > > > > > Pivotal 

Re: IndexType deprecation question

[Jason Huynh]

Hi Joris,

Just some guesses and no actual answer from me here:

The deprecation of the index type was before HASH indexes were created, and
my guess was due to the introduction of the "new at the time" query service
apis (the javadoc:@deprecated As of 6.6.1. Check {@link QueryService} for
changes.)

The internals still use the IndexType as you have pointed out and maybe the
deprecation was more intended for the end user (since it's not an internal
type) and perhaps it was intended to have been moved internal at some
point?

There is some weirdness with the index types and actually having multiple
implementations for the Functional type.  Under the covers we create a
memory-optimized version based on the indexed expression.

Things have changed since deprecation, so maybe it should be
un/de-deprecated or an alternative solution can probably be thought up...

-Jason


On Mon, Dec 2, 2019 at 9:13 AM Joris Melchior  wrote:

> Hi Jason,
>
> At this point it is not about creating but returning the Region with an
> indicator in the management API without using deprecated parts. Under the
> covers the QueryService java api still uses the IndexType ENUM and had
> assumed that an alternative would be provided when something is marked as
> deprecated.
>
> I can of course create a new ENUM to return but prefer not to take this
> step before ensuring that we don't have something in place already.
>
> I'm also wondering if the deprecation should have been limited to the HASH
> type on the IndexType ENUM instead of deprecating the complete ENUM.
>
> Thanks, Joris.
>
> On Mon, Dec 2, 2019 at 12:05 PM Jason Huynh  wrote:
>
> > Hi Joris,
> >
> > How are you creating the index?  If using the QueryService java api,
> there
> > should be createKeyIndex() and createIndex() methods.  These methods
> should
> > create the primary key index and the functional index.
> >
> > I am not sure if there is an alternative in gfsh... it might still be
> using
> > the IndexType enum or something similar.
> >
> >
> >
> >
> > On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior 
> > wrote:
> >
> > > Thanks John.
> > >
> > > I'm trying to use it on the server side for the management API so
> > > unfortunately the Spring wrapper is not an option. Hopefully someone
> can
> > > provide some insight into the deprecation background once all the
> turkey
> > > and stuffing has been digested.
> > >
> > > On Fri, Nov 29, 2019 at 2:16 PM John Blum  wrote:
> > >
> > > > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > > > spring-data-geode), then there is an SDG Index enum type
> > > > <
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > >
> > > > [1]
> > > > wrapping the deprecated Apache Geode Index enum type
> > > > <
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > > >
> > > >  [2].
> > > >
> > > >
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > [2]
> > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > >
> > > >
> > > > On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior  >
> > > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > I notice that the ENUM
> > > > >
> > > > > org.apache.geode.cache.query.IndexType has been deprecated but
> can't
> > > > > find what to use instead of this ENUM if I wanted to use a
> > > > > non-deprecated alternative.
> > > > >
> > > > > I understand that HASH indexes are no longer recommended but the
> > other
> > > > > types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
> > > > > should be able to use them without using deprecated code.
> > > > >
> > > > > Can anyone tell me how this is accomplished?
> > > > >
> > > > > Thanks, Joris.
> > > > >
> > > > >
> > > > > --
> > > > > *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*
> > > > > 
> > > > >
> > > >
> > > >
> > > > --
> > > > -John
> > > > john.blum10101 (skype)
> > > >
> > >
> > >
> > > --
> > > *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*
> > > 
> > >
> >
>
>
> --
> *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*
> 
>

Re: Odg: Lucene upgrade

[Jason Huynh]

Hi Mario,

Sorry I reread the original email and see that the exception points to a
different problem.. I think your fix addresses an old version seeing an
unknown new lucene format, which looks good.  The following exception looks
like it's the new lucene library not being able to read the older files
(Just a guess from the message)...

Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
version is not supported (resource
BufferedChecksumIndexInput(segments_1)): 6 (needs to be between 7 and
9). This version of Lucene only supports indexes created with release
6.0 and later.

The upgrade is from 6.6.2 -> 8.x though, so I am not sure if the message is
incorrect (stating needs to be release 6.0 and later) or if it requires an
intermediate upgrade between 6.6.2 -> 7.x -> 8.





On Mon, Dec 2, 2019 at 2:00 AM Mario Kevo  wrote:

>
> I started with implementation of Option-1.
> As I understood the idea is to block all puts(put them in the queue) until
> all members are upgraded. After that it will process all queued events.
>
> I tried with Dan's proposal to check on start of
> LuceneEventListener.process() if all members are upgraded, also changed
> test to verify lucene indexes only after all members are upgraded, but got
> the same error with incompatibilities between lucene versions.
> Changes are visible on https://github.com/apache/geode/pull/4198.
>
> Please add comments and suggestions.
>
> BR,
> Mario
>
>
> 
> Šalje: Xiaojian Zhou 
> Poslano: 7. studenog 2019. 18:27
> Prima: geode 
> Predmet: Re: Lucene upgrade
>
> Oh, I misunderstood option-1 and option-2. What I vote is Jason's option-1.
>
> On Thu, Nov 7, 2019 at 9:19 AM Jason Huynh  wrote:
>
> > Gester, I don't think we need to write in the old format, we just need
> the
> > new format not to be written while old members can potentially read the
> > lucene files.  Option 1 can be very similar to Dan's snippet of code.
> >
> > I think Option 2 is going to leave a lot of people unhappy when they get
> > stuck with what Mario is experiencing right now and all we can say is
> "you
> > should have read the doc". Not to say Option 2 isn't valid and it's
> > definitely the least amount of work to do, I still vote option 1.
> >
> > On Wed, Nov 6, 2019 at 5:16 PM Xiaojian Zhou  wrote:
> >
> > > Usually re-creating region and index are expensive and customers are
> > > reluctant to do it, according to my memory.
> > >
> > > We do have an offline reindex scripts or steps (written by Barry?). If
> > that
> > > could be an option, they can try that offline tool.
> > >
> > > I saw from Mario's email, he said: "I didn't found a way to write
> lucene
> > in
> > > older format. They only support
> > > reading old format indexes with newer version by using lucene-backward-
> > > codec."
> > >
> > > That's why I think option-1 is not feasible.
> > >
> > > Option-2 will cause the queue to be filled. But usually customer will
> > hold
> > > on, silence or reduce their business throughput when
> > > doing rolling upgrade. I wonder if it's a reasonable assumption.
> > >
> > > Overall, after compared all the 3 options, I still think option-2 is
> the
> > > best bet.
> > >
> > > Regards
> > > Gester
> > >
> > >
> > > On Wed, Nov 6, 2019 at 3:38 PM Jacob Barrett 
> > wrote:
> > >
> > > >
> > > >
> > > > > On Nov 6, 2019, at 3:36 PM, Jason Huynh  wrote:
> > > > >
> > > > > Jake - there is a side effect to this in that the user would have
> to
> > > > > reimport all their data into the user defined region too.  Client
> > apps
> > > > > would also have to know which of the regions to put into.. also, I
> > may
> > > be
> > > > > misunderstanding this suggestion, completely.  In either case, I'll
> > > > support
> > > > > whoever implements the changes :-P
> > > >
> > > > Ah… there isn’t a way to re-index the existing data. Eh… just a
> > thought.
> > > >
> > > > -Jake
> > > >
> > > >
> > >
> >
>

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: IndexType deprecation question

[Joris Melchior]

Hi Jason,

At this point it is not about creating but returning the Region with an
indicator in the management API without using deprecated parts. Under the
covers the QueryService java api still uses the IndexType ENUM and had
assumed that an alternative would be provided when something is marked as
deprecated.

I can of course create a new ENUM to return but prefer not to take this
step before ensuring that we don't have something in place already.

I'm also wondering if the deprecation should have been limited to the HASH
type on the IndexType ENUM instead of deprecating the complete ENUM.

Thanks, Joris.

On Mon, Dec 2, 2019 at 12:05 PM Jason Huynh  wrote:

> Hi Joris,
>
> How are you creating the index?  If using the QueryService java api, there
> should be createKeyIndex() and createIndex() methods.  These methods should
> create the primary key index and the functional index.
>
> I am not sure if there is an alternative in gfsh... it might still be using
> the IndexType enum or something similar.
>
>
>
>
> On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior 
> wrote:
>
> > Thanks John.
> >
> > I'm trying to use it on the server side for the management API so
> > unfortunately the Spring wrapper is not an option. Hopefully someone can
> > provide some insight into the deprecation background once all the turkey
> > and stuffing has been digested.
> >
> > On Fri, Nov 29, 2019 at 2:16 PM John Blum  wrote:
> >
> > > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > > spring-data-geode), then there is an SDG Index enum type
> > > <
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > >
> > > [1]
> > > wrapping the deprecated Apache Geode Index enum type
> > > <
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > >
> > >  [2].
> > >
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > [2]
> > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > >
> > >
> > > On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior 
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > I notice that the ENUM
> > > >
> > > > org.apache.geode.cache.query.IndexType has been deprecated but can't
> > > > find what to use instead of this ENUM if I wanted to use a
> > > > non-deprecated alternative.
> > > >
> > > > I understand that HASH indexes are no longer recommended but the
> other
> > > > types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
> > > > should be able to use them without using deprecated code.
> > > >
> > > > Can anyone tell me how this is accomplished?
> > > >
> > > > Thanks, Joris.
> > > >
> > > >
> > > > --
> > > > *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*
> > > > 
> > > >
> > >
> > >
> > > --
> > > -John
> > > john.blum10101 (skype)
> > >
> >
> >
> > --
> > *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*
> > 
> >
>


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

Re: IndexType deprecation question

[Jason Huynh]

Hi Joris,

How are you creating the index?  If using the QueryService java api, there
should be createKeyIndex() and createIndex() methods.  These methods should
create the primary key index and the functional index.

I am not sure if there is an alternative in gfsh... it might still be using
the IndexType enum or something similar.




On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior 
wrote:

> Thanks John.
>
> I'm trying to use it on the server side for the management API so
> unfortunately the Spring wrapper is not an option. Hopefully someone can
> provide some insight into the deprecation background once all the turkey
> and stuffing has been digested.
>
> On Fri, Nov 29, 2019 at 2:16 PM John Blum  wrote:
>
> > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > spring-data-geode), then there is an SDG Index enum type
> > <
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > >
> > [1]
> > wrapping the deprecated Apache Geode Index enum type
> > <
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > >
> >  [2].
> >
> >
> >
> > [1]
> >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > [2]
> >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> >
> >
> > On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior 
> > wrote:
> >
> > > Hi All,
> > >
> > > I notice that the ENUM
> > >
> > > org.apache.geode.cache.query.IndexType has been deprecated but can't
> > > find what to use instead of this ENUM if I wanted to use a
> > > non-deprecated alternative.
> > >
> > > I understand that HASH indexes are no longer recommended but the other
> > > types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
> > > should be able to use them without using deprecated code.
> > >
> > > Can anyone tell me how this is accomplished?
> > >
> > > Thanks, Joris.
> > >
> > >
> > > --
> > > *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*
> > > 
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>
>
> --
> *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*
> 
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Jens Deppe]

Thanks for the positive feedback. This proposal is accepted and development
will proceed.

--Jens

On Mon, Nov 25, 2019 at 9:27 AM Dale Emery  wrote:

> +ힹ
> —
> Dale Emery
> dem...@pivotal.io
>
>
>
> > On Nov 22, 2019, at 8:39 AM, Jens Deppe  wrote:
> >
> > Hello All,
> >
> > We'd like to propose moving gfsh and all associated commands into its own
> > gradle submodule (implicitly thus also producing a separate maven
> > artifact). The underlying intent is to decouple geode core from any
> Spring
> > dependencies.
> >
> > The proposal is outlined here:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> >
> > Please provide feedback for this proposal *on this email thread* and not
> in
> > the comment section of the proposal page.
> >
> > The deadline for this proposal will be Monday, December 2.
> >
> > Thanks in advance for feedback / comments.
> >
> > --Jens & Patrick
>
>

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[Jens Deppe]

For the purpose of moving this forward, I have merged PR #4311 [1]. From a
runtime POV this now requires a minimum 3.0 servlet compatible container.
Documented minimum, however, is at least 3.1.

I suggest that if anyone would like to see documented newer support that
that should be proposed separately.

Thanks
--Jens

[1] - https://github.com/apache/geode/pull/4311

On Wed, Nov 20, 2019 at 10:15 AM Jens Deppe  wrote:

> To be clear, this proposal just wants to update the *minimum* *documented*
> requirement. The following PR would require that to be 3.0:
> https://github.com/apache/geode/pull/4311
>
> There is no additional change required other than documentation.
>
> --Jens
>
> On Wed, Nov 20, 2019 at 9:46 AM Udo Kohlmeyer  wrote:
>
>> I think that we should really be looking at going to 4.0.
>>
>> It would be compatible with 3.1, but given that 4.0 is standard with
>> Java 8 (which already EOL), we should try and get onto the latest.
>>
>> I don't think that us aligning ourselves with a tech release in 2013 is
>> something we should do.
>>
>> --Udo
>>
>> On 11/20/19 9:17 AM, Jens Deppe wrote:
>> > Since there appears to be consensus, I'm going to give this thread
>> another
>> > 24 hours and will then consider this proposal accepted.
>> >
>> > If anyone does have concerns please do raise them now.
>> >
>> > Thanks
>> > --Jens
>> >
>> > On Sat, Nov 16, 2019 at 8:17 AM Joris Melchior 
>> wrote:
>> >
>> >> +1 for bumping to 3.1
>> >>
>> >> On Fri, Nov 15, 2019 at 10:27 PM Jacob Barrett 
>> >> wrote:
>> >>
>> >>> +1 for 3.1
>> >>>
>>  On Nov 15, 2019, at 3:08 PM, Jens Deppe  wrote:
>> 
>>  +1 to bumping the documented support to 3.1.
>> 
>>  The prompting for this proposal is due to this PR which specifically
>> >>> wants
>>  to utilize a *3.0* API: https://github.com/apache/geode/pull/4311
>> 
>>  Thus implementing this change will not preclude being able to use the
>>  Session Module in a 3.0 container (even if we document support as
>> being
>>  against 3.1)
>> 
>>  --Jens
>> 
>> > On Fri, Nov 15, 2019 at 2:57 PM John Blum  wrote:
>> >
>> > I would minimally bump it to 3.1 then.  Not only does Servlet 3.1
>> open
>> >>> up
>> > more doors (e.g. NIO), but is also implemented by all current
>> Servlet
>> > Container providers (Tomcat, Jetty, etc).  Additionally, given all
>> the
>> > Servlet Containers Jens mentioned at the version that started
>> >> supporting
>> > Servlet 3.0 are no longer supported, then 3.1 seems like a
>> >>> good/reasonable
>> > target.
>> >
>> > -j
>> >
>> >> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith 
>> >> wrote:
>> >> +1 to bumping to servlet 3.0.
>> >>
>> >> -Dan
>> >>
>> >> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith <
>> smith...@macewan.ca>
>> >> wrote:
>> >>
>> >>> Seems to me as long as newer Servlet specs do not deprecate
>> >>> functionality/api that the session module requires AND that the
>> >>> session
>> >>> module is not missing any important functionality provided by
>> newer
>> >> Servlet
>> >>> specs that it's best to base support the oldest Servlet spec that
>> is
>> >> still
>> >>> supported by active container versions. As Jens nicely enumerated,
>> >>> this
>> >>> seems to be Servlet 3.0 right now.
>> >>>
>> >>> At least that's the approach that would give the session
>> management
>> >>> modules the widest audience. I am currently writing a Servlet 4.0
>> >> web
>> > app
>> >>> and the Geode session module is working great except that I need
>> to
>> > layer
>> >>> on an additional filter to ensure my session cookies are secure.
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Charles Smith
>> >>>
>> >>> Developer/Analyst
>> >>>
>> >>> Web Architecture and Development
>> >>> MacEwan University
>> >>> smith...@macewan.ca
>> >>>
>> >>>
>> >>> 
>> >>> From: John Blum 
>> >>> Sent: Friday, November 15, 2019 11:17 AM
>> >>> To: geode 
>> >>> Subject: Re: Proposal to modify Servlet spec support for the HTTP
>> > Session
>> >>> Management Module for AppServers
>> >>>
>> >>> Since the Servlet 3.1 spec is available and the current version is
>> >>> 4.0,
>> >> why
>> >>> not consider 3.1 or even 4.0, actually?
>> >>>
>> >>> -j
>> >>>
>> >>> On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe 
>> >> wrote:
>>  Hello Charles; thanks very much for bringing this up.
>> 
>>  I vote +1 on this proposal.
>> 
>>  Just to add a bit more details for others:
>> 
>>  The 3.0 Servlet Spec was finalized at the end of 2009. The
>> >> *earliest*
>>  versions of various containers that supported it are:
>> 
>> - Jetty 8 (EOL'd since 11/2014) [1]
>> - Tomcat 7 (Version 6 EOL'd 

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

Odg: Lucene upgrade

[Mario Kevo]

I started with implementation of Option-1.
As I understood the idea is to block all puts(put them in the queue) until all 
members are upgraded. After that it will process all queued events.

I tried with Dan's proposal to check on start of LuceneEventListener.process() 
if all members are upgraded, also changed test to verify lucene indexes only 
after all members are upgraded, but got the same error with incompatibilities 
between lucene versions.
Changes are visible on https://github.com/apache/geode/pull/4198.

Please add comments and suggestions.

BR,
Mario



Šalje: Xiaojian Zhou 
Poslano: 7. studenog 2019. 18:27
Prima: geode 
Predmet: Re: Lucene upgrade

Oh, I misunderstood option-1 and option-2. What I vote is Jason's option-1.

On Thu, Nov 7, 2019 at 9:19 AM Jason Huynh  wrote:

> Gester, I don't think we need to write in the old format, we just need the
> new format not to be written while old members can potentially read the
> lucene files.  Option 1 can be very similar to Dan's snippet of code.
>
> I think Option 2 is going to leave a lot of people unhappy when they get
> stuck with what Mario is experiencing right now and all we can say is "you
> should have read the doc". Not to say Option 2 isn't valid and it's
> definitely the least amount of work to do, I still vote option 1.
>
> On Wed, Nov 6, 2019 at 5:16 PM Xiaojian Zhou  wrote:
>
> > Usually re-creating region and index are expensive and customers are
> > reluctant to do it, according to my memory.
> >
> > We do have an offline reindex scripts or steps (written by Barry?). If
> that
> > could be an option, they can try that offline tool.
> >
> > I saw from Mario's email, he said: "I didn't found a way to write lucene
> in
> > older format. They only support
> > reading old format indexes with newer version by using lucene-backward-
> > codec."
> >
> > That's why I think option-1 is not feasible.
> >
> > Option-2 will cause the queue to be filled. But usually customer will
> hold
> > on, silence or reduce their business throughput when
> > doing rolling upgrade. I wonder if it's a reasonable assumption.
> >
> > Overall, after compared all the 3 options, I still think option-2 is the
> > best bet.
> >
> > Regards
> > Gester
> >
> >
> > On Wed, Nov 6, 2019 at 3:38 PM Jacob Barrett 
> wrote:
> >
> > >
> > >
> > > > On Nov 6, 2019, at 3:36 PM, Jason Huynh  wrote:
> > > >
> > > > Jake - there is a side effect to this in that the user would have to
> > > > reimport all their data into the user defined region too.  Client
> apps
> > > > would also have to know which of the regions to put into.. also, I
> may
> > be
> > > > misunderstanding this suggestion, completely.  In either case, I'll
> > > support
> > > > whoever implements the changes :-P
> > >
> > > Ah… there isn’t a way to re-index the existing data. Eh… just a
> thought.
> > >
> > > -Jake
> > >
> > >
> >
>

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