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