I am release my own provider to extend some user account actions and having trouble with token validation in it. I am explore rest example https://github.com/keycloak/keycloak/tree/master/examples/providers/rest , but can`t see how I can do it.
My scenario is next. Client app authenticate user use Direct Access Grant request to retrieve token. Next, I am sending request on my own resource with this token. Then I want to validate token and check user rights for allow access to my method in resource. What is true way to release it?
Center of Financial Techologies
I'm thinking of moving translations to a separate repository.
The plan is to not have them included in the standard distribution and not
part of the release. Often a release comes with changes to the English
message bundles and we can't afford to wait for all translations to be
updated before a release.
The repository would have a page listing the languages and each language
would have a maintainer listed (by Github username). Ideally we'd also have
the page automatically updated with % keys translated and somehow figure
out if it needs to be updated (in the event the English translation has
Adding translations to the base theme should be made as simple as possible.
This will need some work to make as it's not simple at the moment to add
additional translations as it requires a custom theme.
I'm interested in the feature and I would like to contribute to do a pull
request to the keycloak project. My first Idea is to implement a new
"RequestAuthenticator" just like the BasicAuthRequestAuthenticator and to
handle the request inside the method RequestAuthenticator.authenticate().
Does it run in the right direction? If yes, I would like to create a pull
request for further discussions.... If not any other comment or tip is
Now that docs are moved to Gitbook they won't be included in the docs
distribution. That leaves only JavaDoc and Admin REST docs. Should we
consider moving these to the standalone server distro or is it best left as
a separate API docs download?
I'm using the oauth2 token introspection feature in order to validate and
get info about tokens, however I'm not being able to get info of
offline_tokens. Is that possible? Or does it make sense?
Some account services like google for instance record and list activities
happend in an account like: Access Type, Location, Date time.
I think this would make a great addition to the account pages in Keycloak,
since it would help users to detect suspicious account activity early.
What do you think?
Google shows the following information:
* Access Type (Which device was used to access the account: Browser,
For this one could add a device detection library to the account page like
* Location (based on IP-Address)
IP Geolocation could be based on free geolite database
* Date time
Datetime of access + humanized "x mins ago"
* current "access point"
The current "access point" is also shown like:
Your computer uses the IP XXX.XXX.XXX.XXX. (Some Country)
does keycloak currently support to sign and encryption of issued JWT tokens?
According to the org.keycloak.protocol.oidc.TokenManager JWT tokens are
but encryption seems to be not supported at the moment.
I couldn't find a JIRA issue for that so I'm wondering whether this is
already on some agenda...
1. I've implemented a custom JPA entity, let's call it DeviceEntity (by
making direct changes to the org.keycloak.keycloak-model-jpa module, as
Entity SPI is not yet available). Now I want to have an entity, let's
name it DeviceCredentialEntity, that would inherit from
CredentialEntity an would extend it in the follwing ways:
a) it would reference DeviceEntity in a many-to-one manner (one device
supplies several credentials);
b) it would introduce a lockout mechanism (if a device is lost/stolen,
all its credentials should be locked out), maybe a boolean field.
All the custom functionality (assigning devices, locking/unlocking)
will be handled by my extensions; otherwise, device credentials should
behave identically to normal ones.
I see two ways of implementing this:
- extending CredentialEntity directly, adding necessary fields and
making DeviceCredentials live in a separate table. This design is
fairly straightforward, but it will introduce additional SQL and
probably modifications to authenticator (to support per-credential
- not creating a dedicated entity, but rather emulating many-to-one
with many-to-many relationship (intermediate table between devices and
credentials + unique constraint on credential ID) and emulating locked-
out status by setting credential type to something invalid. This is
less clean, but also less intrusive, as it will require no
modifications to authenticator.
Which way is better at the moment (v1.9.7)? Will the upcoming v2.0.0 +
Entity SPI address problems like this?
2. Imagine the storage contains a lot of CredentialEntities with user
field set to null (in other words, a pool of non-owned credentials
available for enrollment). Wouldn't it break the system? Wouldn't these
entities be considered orphaned and be "scavenged" by some kind of
In replicated LDAP setups, it's a common situation where the slave is
read-only, and if a write operation is attempted, it returns a so-
called referral (see more here). Simply put, a referral is an
instruction to proceed with the same LDAP operation but using different
URL, contained within response. In a replicated setup, this URL would
point to master instance, which is read-write.
Currently, KeyCloak cannot use such a slave replica as a federation
provider in a WRITABLE edit mode. LDAP entries are imported
successfully; but further attempts to modify them in KeyCloak admin
console give success message, while the actual values are not modified.
If Sync Registrations is on, attempt to create a user results in the
javax.naming.PartialResultException: [LDAP: error code 10 - Referral];
remaining name 'uid=foo,ou=People,dc=foobar,dc=com'
LDAP referrals are fully supported by JNDI and LDAP stack; the only
thing we need is to set a Context.REFERRAL ("java.naming.referral")
environment property to "follow" before creating an InitialLdapContext.
I've noticed that in org.keycloak.federation.ldap.LDAPConfig, there is
an initial support for additional connection properties (currently
hardcoded to return null). Are there any plans to implement this?