Repository navigation
Replies: 9 comments 16 replies
No, in the new storage it should be possible to keep letter case. The current behaviour does not cover some usecases and we already had RFEs for keeping the letter case as provided:
These RFEs were rejected by the time of their triage since the decision was based on legacy implementation of the storage. The new store may behave differently. I believe the user storage map provider should specify an option whether username letter case is significant or not. If not, let's search by lowercase / uppercase (could be an option of the provider). The storage implementation might lack the feature support for either of these - for example for external sources (say LDAP or REST) it cannot arbitrarily set whether they do or do not support letter case resolution. Keycloak has to follow their settings. |
reading this it seems we should introduce new method variants in Perhaps configuration option defaulting to current behavior could be introduced in map users spi. WDYT? |
It needs to be stressed in Javadoc and later the documentation that the lettercase significance depends on storage, but at this moment I don't see the need to introduce any new method variants in those providers.
Just to be clear - this option should be introduced on the level of map storage user provider factory and applied in appropriate criteria builder, not map users provider factory, so that it is possible to configure the behaviour per realm. |
|
Currently I've created an issue for enabling it: #10245 As part of the issue should be also update of current implementations of |
|
Is there some advantage of having the letter case of stored username configurable? To me, it seems the most important part of this is to have uniqueness check and searching by username case-insensitive (this should be true all the time regardless of how the data are stored). How the username is stored is given by the storage capabilities whether it is able to store things with preserving letter case. |
|
Thank you. The lettercase should be consistent across the stores in the tree. If a map store "above" is not capable of differentiating the letter case, the store "below" should behave as if it was not capable of the same even if technically it it did. As for "searching by username case-insensitive": this is the feature that is considered a bug by some, see the referenced issues above. Thus we need a configurability on whether searching by username is lettercase sensitive or not. |
|
I agree that the store in the future should keep the lettercase, then we rather solve it when looking up user based on username. I can see folks wanting both to solve the problem with LDAP/saml/etc and also still perhaps wanting to just type username with lowercase perhaps. Any ways okay with the change in general as long as current (oddities) don't end up being blockers or breaking behaviour. |
|
On the last team call we've discussed that the best solution, to allow storing username in case-sensitive format and also to be able to support fast search when searching in case-insensitive mode, would be to store both variants of the username (both This decision implies that we might enhance the Then the There would be some stores, added in a future, which won't allow to distinguish letter case. Those stores should throw the Tree store then should manage the setting for the whole tree and ensure it is set correctly. |
|
@vramik Question regarding the usernameSensitivity switch. Should we take it into account only in the method Example: given we have storage configured as case sensitive, and we have the following users /cc @hmlnarik [1] https://github.com/keycloak/keycloak/blob/main/model/map/src/main/java/org/keycloak/models/map/user/MapUserProvider.java#L609 |
|
I think we should keep the current behavior as default new one. As agreed the default should be That being said I've changed it to use It can be changed in case of a need, of course. |
|
Sure, we should keep the default behaviour as is now. So you plan to change also |
|
I've changed it this way in the PR. If there will be a requirement for changing it, I'll update. |
|
Heterogeneous cluster Homogeneous cluster Also it's expected that administrator is responsible there are no-collinding usernames upon change of the setting from |
|
I agree up to this point:
Entity versions should be transparent to the administrator - the administrator would only be notified that migration is needed and decides when to perform it. Depends on background tasks feature. |
|
Sorry if this is not the place to ask, but Is there any new version where you can save usernames with upper case characters? |
|
Hello @mariocozta, the feature is available since keycloak 20 and only for map store, which is currently experimental feature. It can be turned on by property: https://github.com/keycloak/keycloak/pull/13183/files#diff-727c72cf577645ce6b64fd87bb4d5e900113858b705a9f64875d1a0aa5f54026R43 AFAIK there is no plan to introduce the feature to legacy store. |
|
This issue seems to have been fixed in the Map Store (an experimental feature) in Keycloak 20 [1][2][3][4][5]. However, since that feature was removed in Keycloak 23 [6][7], the fix should be ported to the JPA store. There seems to be interest around the port in [8]. [1] #10198 [8] #32869 |
|
Hello ! Is theire now a simple way to retrieve/enable username case sensitive login/retrieve ? I dont see anything about this in the documentation. All issues mention user cache disable, but has i see in this conversation, do you have implement this feature ? |
|
Hello @zelytra, due to unfortunate decision to discontinue Map store[1], which provided this capability, there is currently no way to store case sensitive usernames and I'm not aware of any plans to introduce it to current store. |
|
No official solution okay, but is their any bypass to handle username case ? (Rollback keycloak version, custom mapper or input on register ?) |
|
The current store automatically lowers the case when the user is being created: What you can try to do is to implement you own User Storage SPI: https://www.keycloak.org/docs/latest/server_development/index.html#_user-storage-spi but I do not foresee all the implications, e.g. if Keycloak doesn't expect lowered case username at some places |
|
Alright thank you for your answer ! |
|
@vramik Hello! BTW, the user fedaration driver is used for read-only mode with Augmenting. |
|
Hi are there any upadte on this feature? |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
looking at the code it seems we always store user's username (and also email) in lowered-case format: https://github.com/keycloak/keycloak/blob/main/model/jpa/src/main/java/org/keycloak/models/jpa/JpaUserProvider.java#L110 and https://github.com/keycloak/keycloak/blob/main/model/map/src/main/java/org/keycloak/models/map/user/MapUserProvider.java#L337 even though it's not specified in java-doc.
Then when looking up for a user by the given username it's specified by java-doc that the username should be:
@param username case insensitive username (case-sensitivity is controlled by storage)JpaUserProvideruses named querygetRealmUserByUsername:select u from UserEntity u where u.username = :username and u.realmId = :realmIdand param username is set byquery.setParameter("username", username.toLowerCase())... this query is supported by indexMapUserProvideruses MCB where operatorILIKEis used: https://github.com/keycloak/keycloak/blob/main/model/map/src/main/java/org/keycloak/models/map/user/MapUserProvider.java#L511 ... if it'd be implemented usingILIKEoperator the index couldn't be used.Question: Could it be safely assumed that username is always stored in lowered-case format? Or is that implementation specific?
Based on that we should decide if we could:
MapUserProviderto use operatorEQ:.compare(SearchableFields.USERNAME, Operator.EQ, username.toLowerCase());UserProvider.addUserspecifying that username should be stored as lower-caseUserLookupProvider.getUserByUsernamesaying it is exact case-insensitive searchnote: it probably applies to email as well, but
MapStorageProvider.getUserByEmailis implemented following way:.compare(SearchableFields.EMAIL, Operator.EQ, email);- there is noemail.toLowerCase(), whileJpaUserProviderusesemail.toLowerCase().EDIT: Related issues:
All reactions