In our project, we use the "Hardcoded role" mapper within a configured Identity Provider (also a Keycloak instance, in our case the same but a different realm) to describe that each user logging in via Keycloak shall be given a certain role.
This works perfectly if the mapper is configured before the first login of the user. The configured role is granted to the (cloned) user when he logs in the first time via Keycloak.
But when another "Hardcoded role" mapper is added to configure another role, then the user is not given the other role when he logs in. Only new users logging in the first time get both roles assigned.
Is this on purpose or a bug?
Mit freundlichen Grüßen / Best regards
Open Source Services 2 - Product Group Customer Success Services (INST-CSS/BSV-OS2) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com<http://www.bosch-si.com%3chttp:/www.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
I've created some pull requests and tasks for moving towards standardized
Promises instead of Keycloak's own custom implementation in order to start
a discussion about how to move forward. There has already been some
discussion about plans to migrate away from the current situation in
I believe the first order of business to start migrating towards a better
place would be to start informing Keycloak's users about the change. In
order to do so I propose to make the following changes:
preference of using the native promises. We can accomplish this by updating
the examples used and providing additional documentation of the promiseType
2. Users that are currently using Keycloak should be informed that
standardized promises are preferred and that they should move away from the
current implementation. In order to do so a deprecation warning should be
logged in the console with instructions on how to migrate their existing
I've created the following issues and pull requests for this:
*Updates to the documentation preferring promiseType native*
*Updates to the adapter to inform users of the deprecation*
Furthermore I would like to start a discussion on these changes and how to
move forward after. Feedback on this is greatly appreciated!
In cloud-native application systems, there are various client applications and those applications are not the same level (i.e. security level, alliance level, development level). And generally, a realm manager or a resource server manager wants to set a different timeout to tokens (access token/refresh token) per client. For example, for a client which wants to minimize authentication considering usability, we set the timeout of a refresh token longer enough. For a client which wants to refresh tokens periodically to mitigate the token interception attack, we set the timeout of a refresh token according to the client requirement.
Currently, the timeout of an access token can be overridden per client. However, the timeout of a refresh token (including offline token) cannot be overridden per client.
We'd like to be able to override the timeout of a refresh token (including offline token) per client.
We'd already tried to implement this just like access token lifespan overriding, and create JIRA ticket and PR, but Stian recommended that we should discuss this use case and how to implement in ML, so I opened this thread.
For single sign-on purpose, it is useful to share sessions among clients in a realm.
However, when we implement this, sessions are no longer shared among clients depending on the settings. And this is useful for API management purpose because, for API management purpose, tokens (= sessions) are associated with each client, and should be managed per client.
What do you think about this feature? I would be very happy if you community gives any kind of comment on that.
JIRA ticket is the following.
PR is the following.
In the next few days we'll be looking into implementing backup and restore
functionality for the Keycloak Operator. One of the options we are
considering, is using an export/import functionality. An Operator could
export all realms into a JSON file and put it somewhere in a Persistent
I was wondering, what do you think about this approach? Are there any
guarantees around export/import functionality (especially with the regards
to its format)? Also, would it work for exporting JSON file from Keycloak
and importing it to RHSSO?
In our current workflow of customer onboarding, we are provisioning
customer users from their IDP (like ADFS) into Keycloak via script. As part
of this process once user is created in Keycloak, the script creates IDP
linking for the user and for this purpose script uses the Keycloak username
field and use it in Provider User Id and Provider Username fields of IDP
As Keycloak stores the username in lowercase format the same value with
lowercase gets reflected in the Provider User Id field (e.g.
abhigokhale(a)gmail.com). The problem is if the SAML response contain Name ID
with mix case (say Abhigokhale(a)gmail.com) then Keycloak displays the
message that user with the same email already exist. Please note, we are
using First login flow with only Create User If Unique authenticator
enabled and rest as disabled.
I would like to get your opinion if Keycloak shall handle this scenario as
its storing the username with lowercase.
Thanks & Regards,
I am trying to implement the following scenario with KC. We have two
applications, SP1 and SP2, that use KC. KC has identity broker pointing to
external IDP. Desired scenario:
1. User agent goes to SP1, he's being redirected to KC and then to extIDP
2. User authenticated in extIDP, and being redirected to KC and then to SP1
with some attributes from extIDP
3. SP1 creates user entity in SP2 basing on attributes from extIDP and
attributes collected by SP1
4. User entity in SP2 is synced to user federation store used by KC.
5. User should be able to SSO to SP2. Session in SP2 should obtain
attributes set by SP1.
The problem is 2 different user entities (instances of UserModel) created
at KC at step #2 and #4. I plan to drop 1st entity, and set identity
federation with extIDP for 2nd entity. But we also need to change user
session in KC, it should contain 2nd user entity data. Otherwise SSO to SP2
Surprisingly, I've found a
method org.keycloak.models.UserSessionModel#restartSession that looks like
does the job. I plan to add custom Authenticator and call session reset
How do you think, will it work?
by EXTERNAL Weimer Benjamin (TNG, INST-CSS/BSV-OS2)
I would like to contribute features to the Identity Provider Claim to Role Mapper.
1.) Regex support for claim values: My suggestion for this feature is to introduce a new checkbox in the Claim to Role Mapper to turn regex support for claim value on or off. By default the regex box is unchecked, so currently existing mappers won't change.
2.) Support for multiple claims: Instead of providing one claim and one claim value the idea is to provide a map of claim -> claim value. The role will be assigned when all provided claims match the token. Is it okay to change the existing Claim to Role Mapper for this feature or should I rather introduce a new mapper for this, e. g. Multiple Claim to Role Mapper?
What are your thought on that? Do these two features have a chance to be contributed?
Tel. +49 30 726112-0