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.
I have a use case where the server must accept authorization requests only
when they contain a signed request object (should be configurable per
I have found a way to make the signing of the request object mandatory by
specifying a 'request.object.signature.alg' attribute on the client, but
this only applies if a request object exists in the first place.
I would like to propose a pull request: It defines a new client attribute
'request.object.required'. If this is set to 'true', the client must send a
request object when initiating an authorization request.
Current code can be checked here:
What do you think?
I'm building a custom RealmResourceProvider to be able run a full realm
export and import while the app is running. Since these are sensitive
tasks, I want to secure the endpoint. I think i managed to do that by
"copying" what is done with the adminResource.
Now I want to (integration) test my custom provider
How should proceed to build tests like the ones available in the test suite
Also is this the right approach?
Things I would like to test:
User is connected to master and has create-realm role to be able to import
User is importing from the realm specified in the file to avoid mistakes
User has the role manage-realm to be able to import...
Thanks for your help
We are running 2 standalone instances of keycloak with a shared database(later on a clustered database) in active passive mode using haproxy as the loadbalancer . I had tested some rest services by running the request again with the same bearer token with the active keycloak server down and passive server now becomes active one and it still works.
Can we run 2 instances of keycloak in the standalone mode behind a proxy with a shared database ? Or should we cluster it first using standlone-ha.xml configuration?
What features will be disabled if we use the former way of loadbalancing keycloak
If we had a built-in, clusterable storage mechanism for Keycloak using
Infinispan we would:
* Shorten build times drastically. 30 minutes and growing for me for
JPA builds. Liquibase + JPA startup takes 5-7 seconds on my box.
* Simpler startup. No need to start a DB.
* Reduce memory footprint? I think JPA is responsible for a lot of
I've started some work on this in spare time. I'd say I'd be done in
like 2 months considering the other work I have in queue.
Looking at FineGrainAtomicMap as an implementation. Should make DB
migration simple and replication quicker.
It seems like authorization services break when using them with a pairwise
enabled client. I've not investigated the full extent of this but long
story short, the sub from the token is used in token validation and in
org.keyclak.authorization.common.KeycloakIdentity for some comparisons.
Steps to reproduce:
1. Create pairwise a client with authorization enabled
3. Get access token (client_credentials)
3, Try post a new resource_set
I'm not sure what the best way to fix this is.
1. Re-write token validation and KeycloakIdentity to not rely on the sub in
2. Re-write the pairwise protocol mapper to ignore service accounts (feels
like putting make-up on a pig), or
3. "terminate" pairwise subs, replacing them with the internal sub, before
There are situations where you don't want to use the UMA protocol to obtain
permissions from the server in form of an access token. Reasons can be: you
don't have any privacy requirements or your requirements don't require all
the UMA dance to obtain an access token.
In these situations, you may just want to send a request with the resources
and scopes you want to get access and get back the access token with these
This is what we provide today with the Entitlement API, an alternative that
simplifies how clients can obtain permissions from the server.
However, with the introduction of UMA 2.0 support, we have now a specific
grant type  for obtaining permissions from the server using the token
endpoint. Just like any other OAuth2 grant type, the UMA grant type expects
a HTTP FORM request with some parameters.
The Entitlement API no longer exists but the same behavior can be achieved
with the new UMA grant type that was introduced. In other words, you can
use this grant type to ask for an access token with permissions without
sending a permission ticket but a list of resources/scopes (as parameters)
you want to get access.
The reason for reusing the grant type is that I would like to avoid having
two endpoints for obtaining permissions from the server. I think it makes
Would like to know your opinion if moving the Entitlement API functionality
to this new grant type makes sense and if, maybe, we should have a specific
grant type (based on UMA grant type) that allows authorization requests
without a permission ticket (but a list of resources and scopes you want to
access). As side note, the code for UMA and non-UMA authorization is pretty
much the same, the main difference is on the format of the authorization
I'm working on testing out the cross-datacenter replication configuration
in our development environment and I'm running into some issues.
I stood up some JDG 7.1 instances and some RH-SSO 7.2 instances all running
on my localhost all with different port offsets, followed the
instructions, and everything seemed to work well enough.
Once I got beyond that and tried running RH-SSO and JDG on separate servers
I started running into issues during RH-SSO startup. Looks like RH-SSO
is unable to connect to the remote ___script_cache but that cache isn't
mentioned anywhere in the RH-SSO documentation. The error message (and
online searching) indicates that this cache only allows remote connections
if authorization is enabled. I didn't see any mention of configuration
related to authentication or security for the remote caches in the
At this point we roped in a JDG expert (cc'ed here) and found some
additional Infinispan documentation on how to add authentication to the
*remote* caches within the JDG configuration but nothing much in the way of
adding authentication to the client cache configuration inside RH-SSO that
didn't involve programmatic changes. After some additional searching we
found some info detailing how to add security configurations to a
remote-cache configuration in Infinispan *9.1* but EAP 7.1 is only running
Infinispan *8.2* which doesn't have these changes.
How did you get this working?
Jared Blashka - Identity & Access Management
I see that there is an open issue where we won't be able to create local keycloak users if ldap is down. I am using 3.0.0.Final version of Keycloak and I don't see the issue resolved. Could you please let me if there are plans to fix the issue in the next release