Role mapping IS letter case dependent if the rule to map roles looks at the username field. If the rule looks at the dn or groups fields, then it IS NOT letter case dependent. What this is contingent upon is the datatype of the field (DistinguishedName for dn and groups, and String for username).
Most of the time this works flawlessly, but in the case of LDAP and AD realms, the username, although of type String, is used as part of a DN during a bind operation, during authentication. In this situation the letter casing of the username is not important during authentication but it is still relevant during role mapping.
Given that the username, of type String, is letter case agnostic for certain realms during authentication, should the role mapping process also be agnostic of letter cases when dealing with such users in such realms? I think it should (hence labeling it a bug), but first I think we must make realms express if they account or not for username letter casing.
Pinging @elastic/es-security (:Security/Authentication)
We discussed this in our weekly meeting.
Tim had a good point that an LDAP realm in user search mode can search for users (before the bind) by any attribute, and that you can configure the LDAP server that certain attributes be letter case sensitive. Therefore, in the general case, it is not true that LDAP realms ignore letter case when authenticate.
In fact this issue is not role mapping specific. For example authorization realms and auditing are also impacted if the authenticating realm ignores letter cases in usernames or not.
We converged towards a solution where we would introduce an LDAP realm option that applies a lower case (or upper case) text transform on the username before the username is checked by the authenticating realm. This way the username is brought to a "canonical" form that can be used in the role mapping rules. The big picture is that we _might_ introduce other types of username text transforms to other realm types, but thus far this is the most compelling use case and we wish to proceed with a fix for this specific problem, and not consider other transforms for other realms in this first iteration.
I have labelled it adoptme/help wanted because we don't have capacity to work on this fix at this moment.
This is relevant for other realms too , i.e. OpenID Connect ( see this Discuss topic )
Most helpful comment
This is relevant for other realms too , i.e. OpenID Connect ( see this Discuss topic )