I am using Keycloak with multiple Kerberos user federations, and am
affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only the
first user federation will attempt Kerberos auth.
I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, this
works great for me.
Ricardo's suggestion is to change SPNEGO authenticators in LDAP and
Kerberos user federations to return null instead of 'failed' or 'continue'.
A null return value causes the UserCredentialStoreManager to continue to
the next auth provider instead of failing the Kerberos auth attempt for all
providers if the first provider fails.
I have tested these changes in my deploy and would like to provide a pull
request, but I need some review and maybe a suggestion on how to add a
test. The following commit has the changes I've made so far:
Note I've reduced log noise as authentication attempts are expected to fail
when the Kerberos provider and user realm don't match.
Ricardo had further problems with a false-positive replay attack - my
situation is not affected by this problem so I'd like to push ahead with
this intermediary fix if possible. I'm unaffected because I have separate
realms with no trust, and separate keytab files per federation that contain
only the relevant keytab entry.
Thanks in advance!
Good morning, it's just me or the build on master is broken? I'm trying
to do something really simple, build Keycloak on Linux in new machine
and I'm getting:
[10:10 AM] Bruno Oliveira da Silva: [INFO] Prepared command line : bin/go get github.com/inconshreveable/mousetrap
[ERROR] package github.com/inconshreveable/mousetrap
[ERROR] imports runtime
[ERROR] imports runtime/internal/sys: cannot find package "runtime/internal/sys" in any of:
[ERROR] /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/vendor/runtime/internal/sys (vendor tree)
[ERROR] /home/abstractj/.mvnGoLang/go1.9.2.linux-amd64/src/runtime/internal/sys (from $GOROOT)
[ERROR] /home/abstractj/github/keycloak/testsuite/integration-arquillian/tests/base/target/gopath/src/runtime/internal/sys (from $GOPATH)
It looks like mousetrap is a Windows specific dependency, so I believe
we don't need this to be installed on Linux machines.
Steps to reproduce:
1. rm -rf ~/.m2/repository/ or just mv :)
2. git clone email@example.com:keycloak/keycloak.git
3. mvn clean install -DskipTests=true
Also looks like the following commit introduced the issue:
Am I doing something wrong or missing some step?
I was wondering if anyone has any recommendation in regard to
high-availability during upgrades? or how people are handling service
availability during a service update? Where as before we had leeway for
the occasional midnight 30 downtime, as more projects on-aboard this is
soon reaching the point where scheduled downtime unless an absolute
emergency isn't acceptable.
Is it at all possible to implement a custom protocolmapper that is deployable via /opt/jboss/keycloak/standalone/deployements ?
If my class only implements ProtocolMapper, it works, but if it extends AbstractOIDCProtocolMapper (which in itself implements ProtocolMapper), my keycloak throws NoClassDefFound errors.
This happens on both 4.0.0-beta1 and 4.0.0-beta2.
ir. Thomas Dupont
Ghent University - imec
IDLab, Office 200.010, 10th floor
iGent Tower - Department of Information Technology
Technologiepark-Zwijnaarde 15, B-9052 Ghent, Belgium
T: +32 9 33 14900
I would like to integrate with an external Identity Provider and I wonder
about the best way to hook into this process? As soon as the external IP
authorizes the user with a valid token I would like to do some internal
setup calls and link metadata to the user (attributes) being created by
I know it is possible to extend Keycloak with custom IdentityProviderMapper
extensions but I would like to validate
1) if they are also meant to execute async http requests?
2) what happens if the request fails?
3) are there any other options better suited for this use case?
Thanks for feedback
We’re running Keycloak 3.4.3.Final and trying to configure OpenID role
mappings from federated Realm down, like follows:
<main_realm> <--- User federation <--- <user_group_realm>
, where following role is created in <main_realm>:
and following role is created in federated realm <user_group_realm>:
We are trying to pass role "main_jenkins_admin" via <main_realm> "bearer"
client in bearer token when user is defined in federated realm -
<user_group_realm> and is granted "group_jenkins_admin" role. To achieve
this we created a mapping in <main_realm>:"bearer" to map:
<main_realm>:main_jenkins_admin to <user_group_realm>:group_jenkins_admin
Following some tests, I found that if new user is created in
<user_group_realm> and gets role assignment, like follows:
in <user_group_realm> - group_jenkins_admin
After first login, this user gets correct role assigned in <main_realm>:
in <main_realm> - main_jenkins_admin
If user existed before role mapping has been done on client level; and his
account exists in both - <main_realm> and <user_group_realm>, than
this role mapping is not working for this user.
I think that this behaviour can be found in following code:
* New user mappings creation:
* Update of existing user (which should happen on missing role only, hence
Can I create an issue in JIRA and may be start work on implementation for
this or change to this code is not desired ?
I am migrating an app to MySQL 8 and I found some issues while migrating Keycloak (I’d like to have it in the same DB version, it's optional though).
In order to do fix the issues with Keycloak I forked the keycloak docker images repo and I upgraded the JDBC driver dependency to 5.1.46 and I was able to connect to MySQL 8 but I got some issues because of the strict row size limits.
The concrete error messages is
Error: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs [Failed SQL: ALTER TABLE keycloak.REALM MODIFY CERTIFICATE VARCHAR(4000)]:
The MySQL documentation reference to this issue is https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html
Then I forked the main Keycloak repo and I changed the liquibase migrations to use TEXT types instead of multiple big VARCHAR types for example VARCHAR(4000).
I ran the test suite against the MySQL 8 database as stated here https://github.com/keycloak/keycloak/blob/master/misc/DatabaseTesting.md and everything worked fine.
I posted two pull requests in GitHub to propose this change, is there anything else I should do to promote this change.
Docker Image PR: https://github.com/jboss-dockerfiles/keycloak/pull/115
Keycloak Source PR: https://github.com/keycloak/keycloak/pull/5201
Looking forward to include this before the version 4 release is done.
We are looking into integrating keycloak UMA 2.0 APIs in our platform to
allow users to share resources, ask access to resources, approve sharing,
exactly how it is possible via the Keycloak Account UI.
It looks like the Account UI is currently using directly keycloak java APIs
to do so.
Looking at the current REST API implementation it seems not possible that:
1. A owner shares directly a resource (without the user requesting that).
2. Lists the permissions related to resources of an owner, including also
the information on who requested that.
In our understanding, to obtain 2. we should some how retrieve the
Requester from the TicketStore and attach the information to the response
(but this would "break" the UMA standard, as anyhow parameters as
"returnNames=true" do, so maybe when the request is using "returnNames=true"
we could attach as well the requester name and it).
For 1, we have no clear ideas, if not adding "requester" as well in the
Any hint would be highly appreciated, so that we can work up some
implementation to provide both features.
*Dr. FEDERICO MICHELE FACCA*
*Head of Martel Lab*
0041 78 807 58 38
*Martel Innovate* <https://www.martel-innovate.com/> - Professional
support for innovation projects
Click to download our innovators' insights!
Follow Us on Twitter <https://twitter.com/Martel_Innovate>
Anyone who would like to review the latest wireframe from the "New
Account Management Console" project, keep reading.
The UXD team has created a wireframe for the "responsive" version of the
Applications screen. This is the screen you will eventually see on a
Please leave comments directly on the wireframe. You will need a free
InVision account. Your feedback is greatly appreciated.
We’re running Keycloak 1.9.8 and have been getting intermittent exception stack traces in the logs with the following cause: Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(2550).
After tracing through the Keycloak source code, I believe that I’ve found the culprit to be the event details JSON field:
It seems that this could still be an issue with the latest master branch (or at least you still have the same character limit). Would you like me to create an issue in JIRA? I’m not sure if it would be acceptable to just increase the character limit of the field or remove the limit? If you have a specific idea for how this should be addressed, I’d be willing to contribute a PR.