[keycloak-dev] Support case sensitive usernames

Mon Sep 9 04:45:18 EDT 2019

+1 To option 2 from me as well

Adding an attribute to the user with the unmodified username, then allow
mapping this to a claim in the token (also allowing using the raw
unmodified username instead of modified username in preferred_username).

On Mon, 9 Sep 2019 at 09:01, Marek Posolda <mposolda at redhat.com> wrote:

> Thanks everyone for the feedback!
>
> I treat it that we rather try to not support case-sensitive usernames
> directly in Keycloak. Agree that it adds some complexity and may be
> better to usually address with the mappers. Just did some testing and
> indeed having the mapper at LDAP level to map LDAP attribute like "uid"
> directly to some user attribute in Keycloak together with protocol
> mapper works just fine.
>
> On 06. 09. 19 19:31, Pedro Igor Silva wrote:
> > I also vote for #2 too. IMO, Keycloak does right in regards to case
> > insensitive usernames. The issue also seems to be use-case specific
> > thus should be handled as such.
> >
> > In fact, maybe the attribute could have a more generic name so that it
> > can reference the "raw username" when the user is federated (either
> > from LDAP or any other source). Could you have a switch in LDAP
> > provider to automatically map the "raw username" to tokens ?
>
> Maybe, but not convinced about that ATM. More switches is more
> complexity and LDAP provider already has quite a lot of switches.
> Depends how typical the use-case and how many people/customers use this
> setup in their environment. But since it is possible to achieve with
> current mappers, I rather try to avoid new switch.
>
> Marek
>
> >
> > Regards.
> > Pedro Igor
> >
> > On Fri, Sep 6, 2019 at 1:23 PM Schuster Sebastian (INST-CSS/BSV-OS2)
> > <Sebastian.Schuster at bosch-si.com
> > <mailto:Sebastian.Schuster at bosch-si.com>> wrote:
> >
> >     I would vote for 2). We also have some funny requirements around
> >     usernames of an LDAP we import from to be short and numeric
> >     because of some SAP system that only likes usernames that way.
> >     Instead of using this name as the Keycloak username we used a
> >     special attribute and a mapper like you said and this works like a
> >     charm for us.
> >
> >     Best regards,
> >     Sebastian
> >
> >     Mit freundlichen Grüßen / Best regards
> >
> >     Dr.-Ing. Sebastian Schuster
> >
> >     Open Source Services (INST-CSS/BSV-OS2)
> >     Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin
> >     | GERMANY | www.bosch-si.com <http://www.bosch-si.com>
> >     Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30
> >     726112-100 | Sebastian.Schuster at bosch-si.com
> >     <mailto:Sebastian.Schuster at bosch-si.com>
> >
> >     Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
> >     148411 B
> >     Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
> >     Geschäftsführung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar
> >     Mitrovic
> >
> >
> >
> >
> >     -----Ursprüngliche Nachricht-----
> >     Von: keycloak-dev-bounces at lists.jboss.org
> >     <mailto:keycloak-dev-bounces at lists.jboss.org>
> >     <keycloak-dev-bounces at lists.jboss.org
> >     <mailto:keycloak-dev-bounces at lists.jboss.org>> Im Auftrag von
> >     Marek Posolda
> >     Gesendet: Freitag, 6. September 2019 17:16
> >     An: keycloak-dev at lists.jboss.org <mailto:
> keycloak-dev at lists.jboss.org>
> >     Betreff: [keycloak-dev] Support case sensitive usernames
> >
> >     At this moment, Keycloak internally saves all usernames in the DB
> >     in lowercase. This means that if Keycloak DB contains user "john"
> >     and user fills the login form with uppercase like "John", Keycloak
> >     is still able to find the user because it lowercase the username
> >     from the login form to "john" and then query DB for lookup of
> >     username "john" . At the same time, DB queries have good
> >     performance as they are not needed to be case sensitive.
> >
> >     Also when we import users from the 3rd party user storage like
> >     ldap, we first convert them to lowercase. Unfortunately this
> >     causes issues for some users, as they have LDAP users in uppercase
> >     like "JOHN" and usernames in keycloak tokens are returned in
> >     lowercase like "john", which causes issues in some applications.
> >
> >     I see 2 possibilities to address this issue:
> >
> >     1) Have a switch at the realm level to support case-sensitive
> >     usernames
> >     2) Address this issue at LDAP level and add special attribute to
> >     users imported from LDAP
> >
> >     More details:
> >
> >     The solution (1) has some more flexibility and is not LDAP
> >     specific, however it may either have non-trivial performance
> >     penalty due the case-sensitive DB searches or it may mean
> >     possibility of duplicated usernames different just by cases like
> >     "john", "John" and "JOHN".
> >
> >     I can imagine that switch at realm level will have 3 options
> >     similar to
> >     this:
> >
> >       * (a) Don't support case insensitive usernames (default value and
> >         current behaviour). So usernames are lowercased before saving to
> >         Keycloak DB and before DB searches.
> >       * (b) Support case sensitive usernames with case-sensitive
> >     duplicated
> >         users. If this option is chosen, it will be possible to have for
> >         example 3 separate Keycloak users like "mposolda", "Mposolda" and
> >         "MPOSOLDA". This will mean that users will need to fill exactly
> >         their case-sensitive username on the login form
> >       * (c) Support case sensitive usernames without case-sensitive
> >         duplicated users. If this option is chosen, you will have
> >         case-sensitive user saved in the DB, however it won't be
> >     allowed to
> >         have duplicated usernames different just by cases. So you won't
> be
> >         able to have "mposolda", "Mposolda" and "MPOSOLDA". The third
> >     option
> >         has price-to-pay as DB searches will need to be case-sensitive
> and
> >         hence may have quite bad performance as mentioned for example in
> >         this blog:
> >
> https://alvinalexander.com/sql/sql-select-case-insensitive-query-queries-upper-lower
> >         . I am not even convinced whether to ever support this option, I
> >         rather vote for no. Performance may be better once we move
> >     away from
> >         RDBMS to Keycloak.next storage, but not sure.
> >
> >     2) Address this issue at LDAP level and add special attribute to
> >     users imported from LDAP. That will allow that LDAP user
> >     "MPOSOLDA" can be mapped to Keycloak user "mposolda". At the
> >     Keycloak level, the user "mposolda" will have the attribute like
> >     LDAP_USERNAME with the value "MPOSOLDA" . In this case, people may
> >     need to create protocol mapper, which will map the LDAP_USERNAME
> >     attribute to their token. Protocol mapper can be added to client
> >     scope, which can be added to all required clients. Not sure if
> >     this is workaround or not
> >
> >     So far, I vote for (1) and maybe just add the (a) and (b) options.
> >     WDYT?
> >
> >     Marek
> >     _______________________________________________
> >     keycloak-dev mailing list
> >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >     _______________________________________________
> >     keycloak-dev mailing list
> >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev