Re: [DISCUSS] Deprecate and remove RealmBase#stripRealmForGss
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
Re: [DISCUSS] Deprecate and remove RealmBase#stripRealmForGss
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. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [DISCUSS] Deprecate and remove RealmBase#stripRealmForGss
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
[DISCUSS] Deprecate and remove RealmBase#stripRealmForGss
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? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
