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
michae...@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 u...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
