I have a need to define two (or more) Kerberos federations to support
Kerberos service tickets from either realm. I have a different keytab file
for each realm.
Lets say I create a federation for REALM A with priority 1, and a second
federation for REALM B with priority 2.
When I attempt authentication as a user from REALM A I have no problem, but
a user from REALM B fails.
Checking the logs I can see that KeyCloak attempts to decrypt the REALM B
service ticket with the REALM A keytab and fails. Instead of moving on to
the lower priority REALM B federation, the Kerberos step of the auth flow
fails and moves on to the next step.
Should I raise a new JIRA issue for this problem?
I have successfully fixed this problem in my environment, but I am unsure
as to which approach is best, and want to make sure I'm fixing the issue
for everyone not just myself. Here are two options:
1: Only allow lower priority federations to attempt auth in certain
This solution detects why authentication failed and will only let other
federations attempt authentication if the ticket couldn't be decrypted -
indicating the ticket received was likely encrypted with a different key:
2: Let all Kerberos federations attempt auth in priority order until one
succeeds or all fail.
Are either of these solutions viable?
I found both Kerberos and LDAP federations with Kerberos enabled affected,
so I'm looking at fixing both.
We have a plan to translate keycloak-documentation to Japanese for the
community at our company.
Because there is no place to manage the translation resources in
we are planning to put the resources into own repository and publish
the built documents to our corporate site.
Do you have any concerns?
Of course, we can contribute it if there are any plans to translate it
Nomura Research Institute, Ltd.
What would be the effort required in order to add a Redis connector in place of the classic Infinispan?
Wildfly would have to be updated as well as Keycloak?
Indeed we found out Infinispan extremely difficult to setup and the documentation very complex to digest.
Also being able to plug a Redis cluster would speed up the Keycloak adoption.
What is your opinion on this topic?
Thank you in advance for sharing your thoughts.
I notice that the Keycloak Admin API createUser/updateUser does not
consider the 'realmRoles' and 'groups' in the payload.
Is there any reason for ignoring these data or simply a feature missing?
Is it possible to request an improvement for this, and/or submit a PR on
Hi Keycloak Devs!
Posted this on keycloak-user but didn’t get any response, so trying here.
We are planning on using the Client Registration flow for setting up
clients on login.
This is mainly to more clearly identify each individual device a user
has logged in with.
Are there anyone using this feature in production with a large number
With our current stats, we would probably end up with a million
clients by the end of the year.
1. Will this scale well with the way Keycloak works?
2. If a user loses their device, how should a full revoke & logout be performed?
I could not find an easy way to find all users’ sessions via the
API, nor all clients.
3. Is there an alternative approach to give each user more control
over their device and session?