I just wanted to let this mailing list know that for the Cloudtrust project (https://github.com/cloudtrust), we have developed a certain number modules for Keycloak. These are currently compatible with the version 3.4.3.Final of Keycloak, but we will make them compatible with Keycloak 4.X (where X will be the latest sub-version of Keycloak when we start working on this) as soon as we can. These modules are:
* keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an implementation of the WS-Federation protocol for keycloak. This allows to select the WS-Federation protocol for Keycloak clients and for identity brokers.
* keycloak-authorization (https://github.com/cloudtrust/keycloak-authorization): this module allows the use of the client authorization system to prevent a user which is authenticated in a Keycloak realm to access a given client. It works no matter which protocol is used, and without the client having to support any extra protocol. Note: this solution is a bit hacky, but necessary for one of our use-cases.
* keycloak-export (https://github.com/cloudtrust/keycloak-export): a module adding an endpoint to fully export a realm while Keycloak is still running (no need for restarts!).
PS: I mailed this to both dev and user mailing lists as I believe it may interest members of both mailing lists. However, upon sending to the dev mailing list the first time it bounced. This is the second attempt.
We're considering Keycloak as a solution for us to Authenticate and Authorize users.
We want to have separate realm for a customer but that requires hundreds possibly more realms in one keycloak.
I've looked into the code and currently the main bottle neck I see are calls to:
During application initialization.
I've got a simple solution to one of those usages, so my question is.
What is the general approach to do this?
On github it is "one commit per issue", but the whole problem with many realms looks to have a lot of places to improve, and currently we are blocked by two places:
We would like to have the user's current locale passed along to an
OAuth2 identity provider as a ui_locales parameter.
This would allow the user to select a custom locale on our Keycloak
instance and continue to have same locale on the external IdP.
Any thoughts on such a feature?
I have created an example implementation, see
and I will add tests and create a PR if you would like to merge it.
Appreciate if you can help me with an issue i have with password policies federating from Keycloak (v3.4.3) to OpenLDAP. I have created 2 password policies on the OpenLDAP server, where i require one for end users and one for service accounts - these are defined in the specific OU's to where the accounts are held.
I have set the password policies for both users and service accounts (policy module, schema, overlay etc..) and can confirm that the policy is being picked up on the OpenLDAP host when i run the command ldappasswd for the user and enter less characters than the required password length (for example)
The issue i have is that within keycloak i haven't set any password policies as i would like this to use the one i have created within the OpenLDAP server. Can Keycloak be configured that this must check against the OpenLDAP password policy? I have one realm set up along with a client.
I have been trying to get this working now for the last 10 days and not getting very far.
Within my LDAP Mapper i have tried creating a msad-user-account-control-mapper however this does not work, i get provided with an error when resetting my user password "Failed to update password in Active Directory. Exception message: [LDAP: error code 17 - pwdLastSet: attribute type undefined"
I would have expected something like this considering i am not using AD.
Any suggestions would be appreciated
Currently the LocaleHelper#getUserLocale chooses locale priority based
on the following order:
1. kc_locale query parameter
2. Locale cookie
3. User profile
4. ui_locales query parameter
5. Accept-Language http header
We are building clients which uses the ui_locales parameter to select
localization of the login to match the locale of the client.
Since the locale cookie has a higher priority than the ui_locales
query parameter, the ui_locales query parameter is ignored for any
auth requests with a kc_locale cookie present.
1. Do you see any implications of prioritizing the ui_locales
parameter above the locale cookie when resolving locale?
2. Are there reasons why the ui_locales does not update the locale
cookie value the same way kc_locale parameter does it?
Keycloak 4.1, standalone-ha, postgres db:
As a part of our migration to keycloak, we have a custom authenticator we
are using for the direct grant flow which will "lazily create" users.
If we fail to find the user in local storage, we create the user with
session data from a legacy IDP. This works well, except in the rare case
where multiple services are authenticating a user for the first time, we
end up with a race condition that yields a ModelDuplicateException:
[0m [31m17:31:41,417 ERROR
[org.keycloak.services.error.KeycloakErrorHandler] (default task-8)
Uncaught server error: org.keycloak.models.ModelDuplicateException:
org.hibernate.exception.ConstraintViolationException: could not execute
at com.sun.proxy.$Proxy79.flush(Unknown Source)
Ideally we could avoid a 500 response and have the race 'loser' look up the
newly created user, but the session's transaction gets marked rollback, and
further lookup/sql operations fail.
I am not finding a way to flush or restart the transaction state in the
I have implemented a failureChallenge that is essentially a 302 redirect
back to the same token endpoint, but there are circumstances where a
redirect loop occurs. I can sort out and handle these cases, but it feels
a bit crufty.
Is there a better/prescribed way to recover from JPA session errors in a
Was thinking some more about how to share certificate functionality between
user authentication and client authentication. Potentially also to SAML.
We could add a Truststore SPI. The TruststoreProvider interface would have
something like the following methods (quick mock stuff):
* boolean verifyCert(CertificateMatcher matcher)
* Set<String> listExpiring()
* void trustCert(Cert cert)
* void removeTrustedCert(String id)
* Cert getSavedCert(String id)
* void removeSavedCert(String id)
* void saveCert(Cert cert)
We'd have a default built-in TruststoreProvider. Potentially delegating
some stuff to Elytron, but it would have to store certs in the db. It would
deal with checking if cert is still valid, call cert validation like the
user cert does, etc..
For user and client authentication we'd use verifyCert primarily. We'd have
something like UserCertMatcher.create()... and
ClientCertMatcher.create()... In the admin console we could add an option
to add trusted certs (not sure how that'd work in a cluster). For SAML
clients we'd delegate storing certs to the Truststore SPI instead of
storing the cert data alongside the client. The truststore would also add
some metadata in the db about certs so we can easily query for expiring
Anyone know what this file is doing there? It seems to be a copy
It seems this is copied when you run mvn build, but that results in changes
to ./src/test/resources/log4j.properties not taking affect when you're
working from the IDE.
Currently, Keycloak always use RS256 both for access tokens and id tokens.
We're working on introducing support for more algorithms and the ability to
change the default for a realm and also for a client.
Now the question is should have we two options one for access token and
another for ID token. Or just one for both?