i am interested is there any solution planned for this issue:
Is it not needed to solve or better option exist for users to authenticate
with certificates to Keycloak while having FreeIPA as a IdM/IdP?
are there any plans to support custom attributes to be passed from
authenticators to (login-) forms?
Concrete use-case is that I want to pass information
from a custom OTP authenticator down to the login-totp.ftl template.
Would be helpful if it were possible to pass custom attributes to the
create*Page(..) methods in org.keycloak.forms.login.LoginFormsProvider.
This would really ease customizations.
Other alternatives to pass data are:
- use some ThreadLocal storage within an Authenticator (set and clear) -
but this feels more like a hack
- custom page template and population logic in in a custom
FreeMarkerLoginFormsProvider (quite involved...)
I need to retrieve SAMLResponse as is after login using Keycloak. I
am able to retrieve SAMLPrincipal and other variables. But, I am not
able to see the parameter "SAMLResponse".
What is the way to get it?
I've been working on online Export functionality for Admin Console
Primary use case is to get core realm configuration with identity providers
and user storage, but no users, and optionally also excluding clients,
roles, and groups. As opposed to offline export (at startup time), which
can serve as a backup to restore the server, the idea of online export is
to help gather server configuration for troubleshooting so you can
reproduce / diagnose issues.
In terms of implementation the idea was first to just trigger the same
logic that creates a single JSON export during offline export, just filter
it to have less content, and no secrets. Then one would ssh to the server
to retrieve the file. But, that's a complicated workflow, especially when
dealing with a cluster of servers - how to know which server performed the
A more usable implementation would be to download the exported JSON through
Admin Console. That does return a lot of information through a simple REST
request - anybody sees any issues here?
Another thing is to be careful that triggering an export does not slow or
block processing of other requests to the server. Current implementation
performs single file export within a single UserTransaction. With no users,
groups, roles, and clients there should be no issues here. But if exporting
many thousands of clients, that might interfere with normal operation of
One idea how to prevent that is to hardcode a fixed limit on instance count
for groups, roles, and clients. Export page would display client count next
to toggle button for exporting of client, and analogous for groups, and
roles. If count is greater than let's say 10k, the toggle for that
inclusion would be disabled. That will require an extra rest endpoint for
gathering these counts. To consistently enforce the limits the check would
have to be performed inside Admin REST export call as well.
Such implementation is more complicated but the whole workflow to get to
exported JSON is much better.
Any thoughts on such an approach?
I've been using keycloak 2.4.0.FINAL.
I've implemented codes for RFC 7636 for Proof Key Code Exchange experimentally.
[Background: Why RFC7636 is necessary]
RFC 7636 is important for industries where high level security is required because it can prevent Authorization Code Interception and Substitution attacks for OAuth2.0. For example, it is required for both confidential and public clients in draft specification of Financial API of OpenID foundation. By implementing RFC 7636, keycloak will be used more widely.
[Description of the implementation]
My implementation is about 90steps for Authorization Server, 90steps for Client(only Servlet-OAuth), both excluded debug log codes in step counts. Please see the detail in below links.
* The implementation:
It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto master branch for PR if you accept our implementation proposal.
* Design document:
* PoC test:
I've validated my implementation and found worked well in following scenarios.
Flow: Authorization Code Flow
Client: RFC 7636 not supported
Flow: Authorization Code Flow
Client: RFC 7636 supported and operate properly
Flow: Authorization Code Flow
Client: RFC 7636 supported but operate illegally
(send invalid code_verifier to Token Endpoint)
For detail of PoC test, please see:
I am also willing to add tests to community’s testsuites according to the process as described in “Hacking on Keycloak”.
I've known that related ticket had already been issued as KEYCLOAK-2604.
Would you mind if I contribute this RFC 7636 support to Keycloak related with KEYCLOAK-2604 ticket ?
Ahoy, I'm writing some tests for this
https://issues.jboss.org/browse/KEYCLOAK-4445 and would like to know if
this is the appropriate place for testing E-mail settings.
It looks like console module is not part of our tests.
Thanks in advance.
Here's how I am going to model role mapping with fine grain permissions
in Authz service. The goal of this is to be able to limit or expand on
who can map specific roles. While we want to have a default that any
admin that has the "manage-users" role can map a role, we also want to
be able to do things like saying that an admin can map a specific role
if they belong to a group instead.
* "permit all" policy. Just grants it.
* "Default Role Mapping Policy" Policy. This is an aggregate policy
that includes the "permit all" policy.
* "map-role" scope
* "Roles" resource. Associated scope is "map-role"
* "Default Role Mapping Permission" - scope permission that binds
"Roles" resource and "map-role" scope. The associated policy will be
"Default Role Mapping Policy".
* "manage-users" scope
* "Users" resource. Associated scope is "manage-users"
* "manage-users" policy that checks that "manage-users" role is present
* "Default Manage Users Policy". This is an aggregate policy that
includes the "manage-users" policy.
* "Default Manage Users Permission". scope permission that binds
"Users" resource and "manage-users" scope. The associated policy will
be "Default Manage Users Policy".
The above defines the default policy for mapping all roles. In the
admin console "Roles" section, there will be a "Default Admin
Permissions" tab. Here the user will be able to modify the "Default
Role Mapping Permission". The will be able to create and add new
policies for this permission. They will not be able to create any other
permission. In the "Users" section of the admin console, there will be
a "Default Admin Permissions" tab. Here the admin will be able to
modify the "Default Manage Users Permission"
FINE GRAIN PERMISSION
For more fine grain permissions, there will be a resource created per
role on demand. The admin will go to the role's console page and there
will be a "Admin Permissions" tab. The admin will say they want to add
a fine grain permission for that role and this will trigger these actions:
* A resource will be created specifically for that role with an
associated scope of "map-role"
* A scope permission will be created for that role resource and the
"map-role" scope. The "Default Role Mapping Policy" will be added
automatically to this permission.
THere will also be a "Admin Permissions" tab for each Group. The admin
will say they want to add a fine grain permission for that group and
this will trigger these actions:
* A resource will be created specifically for that group with an
associated scope of "manage-users"
* A scope permission will be created for that group resource and the
"manage-users" scope. The "Default Manage User Policy" will be added
automatically to this permission.
When evaluating whether or not a role is allowed to be mapped by a
particular admin, this will be the algorithm:
1. If there is a resource for that specific role, evaluate that the
admin can use the "map-role" scope with that role's resource
2. If there is not a resource for that specific role, then evaluate that
teh admin can use the "map-role" scope with the "Roles" resource.
3. Evaluate if the admin can perform the "manage-users" scope on the
4. If Step #3 fails, then for each group see if the admin has the
"manage-users" scope for that group.
DEFAULT PERMISSIONS FOR ADMIN ROLES
By default, each admin role in the system "manage-users",
"manage-realm", etc... will have a resource ad scope permission created
for it as articulated above. The scope permission will be UNANIMOUS and
will also associate a role policy of that role in addition to the
"Default Role Mapping Policy". This additional role policy is basically
saying "Admins with 'manage-users' role and the admin must have this
role mapping as well". So, somebody with 'manage-users' role can't map
'manage-realm' unless they have that role themselves.
MORE FINE GRAIN PERMISSIONS
We also want to solve the case of allowing an admin to be able to map
specific roles for members of a specific group. To do this we'll add
another policy type called "Has Permission". Here you'll be able to
link a permission to a policy. So, to solve the use case for specific
roles for members of a specific group, we can edit the "map-role"
permission for a specific role and add a "Has Permission" that links to
the permission that the admin has "manage-users" scope for a specific
group. Hope I'm making sense on this one.
I wrote a small Keycloak extension  that exposes a health endpoint
with health-checks as a RealmResource.
Health Checks can be contributed with a dedicated SPI.
(I took some inspiration from Spring Boot and Wildfly Swarm Health-Checks:
I'm now looking for general feedback and suggestions for additional health
that could be added (infinispan?) - perhaps this could even be added to
Some things I noticed:
1) RealmResourceProvider allows to expose custom JAX-RS resources on realm
there is no equivalent for "global" Resources, e.g. something like
KeycloakResourceProvider / PublicResourceProvider is missing.
I wanted to add health-check for the whole Keycloak Server not just a
2) It seems that many requests lead to a database tx being commited via
org.keycloak.services.filters.KeycloakTransactionCommitter, even if there
is no write to the database.
Is this intended?
3) The keycloak-server BOMs didn't work for me. Even if I declare
in my pom.xml I need to provide <version> settings to keycloak
which shouldn't be the case with a correct maven BOM.
I tried this with keycloak version 2.5.5.Final and 3.0.0.Final