KEYCLOAK_SESSION not working for some user federation setups

Describe the bug

In some cases with user federation, the ID of the user can contain some special characters. For example when configured LDAP provider with “Import Users” set to OFF and with “UUID LDAP Attribute” set to “uid” . Then when you have some user with special character in the “uid”, this is in turn used as the ID of the user. And this is saved in the KEYCLOAK_SESSION cookie:

KEYCLOAK_SESSION=**:spécial.char/**; 
KEYCLOAK_SESSION_LEGACY=***; 

The character “é” is present in the cookie name, which is not allowed by the undertow server. In the log is this (likely when accessing Keycloak from some Javascript application when the particular user with special character is logged):

ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /auth/realms/defence-intra/protocol
/openid-connect/login-status-iframe.html: java.lang.IllegalArgumentException: UT000173: An invalid control character [233] was 
present in the cookie value or attribute

Version

19.0.1

Anything else?

For the fix, it is probably easiest to Base64Url encode the cookie KEYCLOAK_SESSION (and maybe some other related cookies, not yet sure for which of them is this applicable) to make sure that there are not special characters in these cookies.

[mposolda]

@pedro-hos I’ve did some digging and ended up creating alternative PR for this - https://github.com/keycloak/keycloak/pull/14560 . It uses URL Encoding instead of Base64Url just for the backwards compatibility (although Base64Url will probably work as well).

[pedro-hos]

Hi @mposolda I see now that you suggested using Base64Url, I can change my implementation if necessary. I create a StringUtils under server-spi. Another questio, I don’t know if this fix also the KEYCLOAK_SESSION_LEGACY. Let me know if I need to change somewhere else.

Thanks Marek!