currently it is hard to figure out what actually happend when processing
events, since there
is no explicit information about the actual underlying resource in an
event. Currently one has to
parse the resourcePath of an AdminEvent to deduce the involved resource.
E.g. Creating a user yields:
Assigning a client role to a user yields:
Removing a client role from a user yields:
It would be helpful if one had more information about the actual use case.
How about introducing an AdminEvent#getResourceType() method that returns
an enum value for the
resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
This would make it easier detect what actually happend without having to
parse the resourcePath.
What do you think?
I am working on a NodeJS Express application using bearer only authentication with Keycloak. It contains a REST API for use by other applications.
Up until now I have been using the Keycloak Connect middleware to secure my POST method, which is a great solution for basic authentication as is almost completely takes it out of the hands of the developer. However, now I need to be able to get a token directly and keep it for a given duration, say 15 minutes, for use by multiple connecting clients.
This token will be used by multiple applications connecting via this REST API, possibly in very quick succession. It needs to be possible to verify that the token is still valid synchronously on the fly, renewing it if required. Is there anything perhaps in the "keycloak-auth-utils" npm package which can get used to handle this? Or any other existing libraries?
I found that the keyclock.update() didn't update any tokens, as the
property timeSkew was left uninitialized.
I've created https://issues.jboss.org/browse/KEYCLOAK-2322 and a Pull
Request https://github.com/keycloak/keycloak/pull/2032 that worked for
me both in 1.7.0 and 1.8.CR1
timeSkew can now also be passed as a parameter to the init options with
a default of 0.
As timeSkew needs to be set every time setToken is being called, I
wonder if I should refactor the code to add a timeSkew to the signature
of setToken(). Should this be done as part of this ticket, in in another
I'm also missing a place where to put some tests for this. Where would I
find the test suite for this?
Alexander Schwartz (alexander.schwartz(a)gmx.net)
I’m integrating an Spring Boot app with KeyCloud and I can’t authenticate with server because the web.xml doesn’t read by Spring Boot.
failed verification of token: Token type is incorrect. Expected 'Bearer' but was 'null'
I’ve tested with spring boot adapter (with tomcat 8 adapter) but I can’t specify properties such transport-guarantee (token) and I’ve tested with spring security too (creating extension of KeycloakWebSecurityConfigurerAdapter)
What’s your solution?
Sent with Airmail
Keycloak 1.8.0.CR1 has just been released. As usual we will follow with a
final release next week as long as no major issues are reported.
- *Default Admin User Removed* - we no longer have a built in admin
account, instead a new account has to be created initially from
http://localhost:8080/auth or with the bin/add-user[sh|bat] script
- *Client Templates* - with the introduction of client templates it's
now possible to share mappers and scope configuration between clients
- *Partial Import* - it's now possible to import users, clients,
identity brokers and user federators from a json file into an existing realm
- *Truststore SPI* - we've introduced a Truststore SPI which provides a
centralized place to manage the truststore for clients, email, user
federation and identity brokering
- *Password Hashing SPI* - if you want to import existing users into
Keycloak you can implement a password hashing provider so existing hashed
passwords can be used (thanks to tsudo <https://github.com/tsudot> for
- *Identity Brokering Login Flow* - this allows customizing the flow
used when a user logs in through an identity broker
- *SAML v2 Enhanced Client or Proxy Profile (ECP)
<http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile>* - this
SAML profile is useful for non-browser based clients (for example a desktop
- *OAuth2 Token Introspection <https://tools.ietf.org/html/rfc7662>* -
the OAuth2 token introspection specification provides a standard way to
obtain the active state of a token
- *Conditional OTP* - requiring OTP used to be either enabled or
disabled for a realm, it's now possible to conditionally choose which users
require OTP based on for example a role or a request header (thanks to
thomasdarimont <https://github.com/thomasdarimont> for the contribution)
- *Realm Display Name* - a display name has been added to realms, which
makes it possible to set a human readable name to be shown on login
screens, emails, etc.
- *WildFly 10.0.0.CR5* - Keycloak is now built on top of WildFly
10.0.0.CR5. Deploying the server overlay to WildFly 9 is no longer supported
For the full list of issues resolved check out JIRA
to download the release go to the Keycloak homepage
I'm changing browse refresh behavior again.
I've removed all the extra redirects, so now, you can end up being on
the OTP page, but the URL is the one posted to by password page. Refresh
page will repost the password, keycloak will see that the current action
is not the same, and just ask the flow to put the browser in the right
state. Similarly with required actions.
JBoss, a division of Red Hat