+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(a)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(a)bosch-si.com
> <mailto:Sebastian.Schuster@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(a)bosch-si.com
> <mailto:Sebastian.Schuster@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(a)lists.jboss.org
> <mailto:keycloak-dev-bounces@lists.jboss.org>
> <keycloak-dev-bounces(a)lists.jboss.org
> <mailto:keycloak-dev-bounces@lists.jboss.org>> Im Auftrag von
> Marek Posolda
> Gesendet: Freitag, 6. September 2019 17:16
> An: keycloak-dev(a)lists.jboss.org <mailto:
keycloak-dev(a)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-...
> . 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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev