[DISCUSS] Deprecate and remove RealmBase#stripRealmForGss

[Michael Osipov <mi...@apache.org>]

Folks,

I'd like to propose to get rid of that config option in 10 and deprecate 
in previous versions for the following reasons:

* It suffers from abstraction: It assumes that the GSS name is always 
email style w/o checking its OID
* The realm part, if any, is an integeral part of the principal. Much 
like with an email address' domain. You wouldn't stip here too, would you?
* It is a surprise for clients having the princippal mutilated by 
default. I trip over and over again this when I set up 
UserDatabaseRealms for testing purposes I wonder why 
michael-o@EXAMPLE.COM does not work.
* In a multi realm environment, it is perfectly fine and valid to have 
user1@REALMA and user1@REALMB. These are distinct principals, but 
treated by RealmBase equally, this has implications.
* Finally, when doing cert-based auth in an AD envinronment, is it 
pretty common to extract the msUPN name from the cert's SAN which is 
almost always email address (enteprise principal) which would end up in 
michael.osipov, but where is the rest?!

Thoughts?

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [DISCUSS] Deprecate and remove RealmBase#stripRealmForGss

[Michael Osipov <mi...@apache.org>]

Am 2020-10-13 um 21:08 schrieb Michael Osipov:
> Am 2020-10-13 um 12:32 schrieb Mark Thomas:
>> On 13/10/2020 10:48, Michael Osipov wrote:
>>> Folks,
>>>
>>> I'd like to propose to get rid of that config option in 10 and deprecate
>>> in previous versions for the following reasons:
>>>
>>> * It suffers from abstraction: It assumes that the GSS name is always
>>> email style w/o checking its OID
>>> * The realm part, if any, is an integeral part of the principal. Much
>>> like with an email address' domain. You wouldn't stip here too, would 
>>> you?
>>> * It is a surprise for clients having the princippal mutilated by
>>> default. I trip over and over again this when I set up
>>> UserDatabaseRealms for testing purposes I wonder why
>>> michael-o@EXAMPLE.COM does not work.
>>> * In a multi realm environment, it is perfectly fine and valid to have
>>> user1@REALMA and user1@REALMB. These are distinct principals, but
>>> treated by RealmBase equally, this has implications.
>>> * Finally, when doing cert-based auth in an AD envinronment, is it
>>> pretty common to extract the msUPN name from the cert's SAN which is
>>> almost always email address (enteprise principal) which would end up in
>>> michael.osipov, but where is the rest?!
>>>
>>> Thoughts?
>>
>> No objections to changing the default to false in 10.0.x but I think
>> removal/deprecation is a step too far.
> 
> OK
> 
>> Not everyone uses the full user@bigco.com format as the "primary key" in
>> their internal user database. I see lots of variation depending on which
>> system is viewed as the source of truth to which other systems are
>> synchronised.
> 
> So you will never be able to satisfy all, why try?
> 
>> We have X509UsernameRetriever for certificate authentication. That came
>> out of bug 52500 where the aim was to support a wide variety of formats.
>> The root of that requirement was essentially the same - integration with
>> a variety of systems where the user name could be in in a range of
>> formats. The mapping of that format to an X509 cert just added another
>> layer of complexity.
> 
> I don't think that this compares (well( because a certificate is a 
> complex object explicitly containing SAN which contain wellknown forms 
> for an entity whereas a GSS name is merely a string with an identifier 
> for its format. Your argumentation could also be applied to an LDAP 
> bind. Active Directory, for instance, accepts a various amounts of input 
> formats for the same entity, yet we don't provide a logic to normalize 
> them in the JNDI Realm. That seems to be unfair to me.
> It lacks a bit of consistency.
> 
>> If there was user demand for it (I haven't seen any) I'd support a
>> similar interface for SPNEGO. With such an interface in place,
>> deprecation and removal of stripRealmForGss would make sense.
> 
> See above.

What we basically miss is a Java counterpart of GSS-API's gss_localname().

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [DISCUSS] Deprecate and remove RealmBase#stripRealmForGss

[Michael Osipov <mi...@apache.org>]

Am 2020-10-13 um 12:32 schrieb Mark Thomas:
> On 13/10/2020 10:48, Michael Osipov wrote:
>> Folks,
>>
>> I'd like to propose to get rid of that config option in 10 and deprecate
>> in previous versions for the following reasons:
>>
>> * It suffers from abstraction: It assumes that the GSS name is always
>> email style w/o checking its OID
>> * The realm part, if any, is an integeral part of the principal. Much
>> like with an email address' domain. You wouldn't stip here too, would you?
>> * It is a surprise for clients having the princippal mutilated by
>> default. I trip over and over again this when I set up
>> UserDatabaseRealms for testing purposes I wonder why
>> michael-o@EXAMPLE.COM does not work.
>> * In a multi realm environment, it is perfectly fine and valid to have
>> user1@REALMA and user1@REALMB. These are distinct principals, but
>> treated by RealmBase equally, this has implications.
>> * Finally, when doing cert-based auth in an AD envinronment, is it
>> pretty common to extract the msUPN name from the cert's SAN which is
>> almost always email address (enteprise principal) which would end up in
>> michael.osipov, but where is the rest?!
>>
>> Thoughts?
> 
> No objections to changing the default to false in 10.0.x but I think
> removal/deprecation is a step too far.

OK

> Not everyone uses the full user@bigco.com format as the "primary key" in
> their internal user database. I see lots of variation depending on which
> system is viewed as the source of truth to which other systems are
> synchronised.

So you will never be able to satisfy all, why try?

> We have X509UsernameRetriever for certificate authentication. That came
> out of bug 52500 where the aim was to support a wide variety of formats.
> The root of that requirement was essentially the same - integration with
> a variety of systems where the user name could be in in a range of
> formats. The mapping of that format to an X509 cert just added another
> layer of complexity.

I don't think that this compares (well( because a certificate is a 
complex object explicitly containing SAN which contain wellknown forms 
for an entity whereas a GSS name is merely a string with an identifier 
for its format. Your argumentation could also be applied to an LDAP 
bind. Active Directory, for instance, accepts a various amounts of input 
formats for the same entity, yet we don't provide a logic to normalize 
them in the JNDI Realm. That seems to be unfair to me.
It lacks a bit of consistency.

> If there was user demand for it (I haven't seen any) I'd support a
> similar interface for SPNEGO. With such an interface in place,
> deprecation and removal of stripRealmForGss would make sense.

See above.

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [DISCUSS] Deprecate and remove RealmBase#stripRealmForGss

[Mark Thomas <ma...@apache.org>]

On 13/10/2020 10:48, Michael Osipov wrote:
> Folks,
> 
> I'd like to propose to get rid of that config option in 10 and deprecate
> in previous versions for the following reasons:
> 
> * It suffers from abstraction: It assumes that the GSS name is always
> email style w/o checking its OID
> * The realm part, if any, is an integeral part of the principal. Much
> like with an email address' domain. You wouldn't stip here too, would you?
> * It is a surprise for clients having the princippal mutilated by
> default. I trip over and over again this when I set up
> UserDatabaseRealms for testing purposes I wonder why
> michael-o@EXAMPLE.COM does not work.
> * In a multi realm environment, it is perfectly fine and valid to have
> user1@REALMA and user1@REALMB. These are distinct principals, but
> treated by RealmBase equally, this has implications.
> * Finally, when doing cert-based auth in an AD envinronment, is it
> pretty common to extract the msUPN name from the cert's SAN which is
> almost always email address (enteprise principal) which would end up in
> michael.osipov, but where is the rest?!
> 
> Thoughts?

No objections to changing the default to false in 10.0.x but I think
removal/deprecation is a step too far.

Not everyone uses the full user@bigco.com format as the "primary key" in
their internal user database. I see lots of variation depending on which
system is viewed as the source of truth to which other systems are
synchronised.

We have X509UsernameRetriever for certificate authentication. That came
out of bug 52500 where the aim was to support a wide variety of formats.
The root of that requirement was essentially the same - integration with
a variety of systems where the user name could be in in a range of
formats. The mapping of that format to an X509 cert just added another
layer of complexity.

If there was user demand for it (I haven't seen any) I'd support a
similar interface for SPNEGO. With such an interface in place,
deprecation and removal of stripRealmForGss would make sense.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org