It seems that "token-store: cookie" is not implemented for the Spring
Security adapter. I would be happy to have a go at it, if nobody objects.
One thing I'm wondering is why the cookie path for the adapter state cookie
is always set to the context root in CookieTokenStore. In particular, it
would seem that if I change the Spring Security adapter in a
straightforward way to store the cookies, the cookie would always be set on
"/sso", which would not be very useful.
A second question I had is about the redirect after login. Currently the
redirect location is stored in the HTTP session. Since you would typically
enable "token-store: cookie" to get rid of HTTP sessions, that would also
have to change. I couldn't really figure out how other adapters were doing
this, and I don't have the time at the moment to experiment with the other
adapters to see what happens; if someone could give me some pointers then
that would be very helpful.
We've just released Keycloak 3.2.0.CR1.
To download the release go to the Keycloak homepage
HighlightsFine grained admin permissions
This is something that we've wanted to add for a long time! Through our
authorization services it's now possible to finely tune permissions for
admins. This makes it possible to limit what clients, users, roles, etc.
admins have access to. Documentation is missing for this at the moment, but
will be added in time for 3.2.0.Final.
Docker Registry support
It's not possible to secure a Docker Registry with a standard OAuth or
OpenID Connect provider. For some strange reason they have only partially
followed the specifications and the Docker Registry maintainers refuse to
fix this! Fear not, thanks to cainj13 <https://github.com/cainj13> who
contributed this we now have a special Docker Registry protocol that can be
enabled in Keycloak.
Authentication sessions and access tokens
In the effort to provide support for running Keycloak in multiple data
centers we've done a large amount of work around user sessions. We've
introduced authentication sessions that are special sessions used primarily
during the authentication flows. There are two main reasons for this.
Authentication flows can fairly easily be fixed to a specific node within a
specific data center and there is no need to replicate this to other data
centers. They are also more write heavy than the user sessions. The
introduction of access tokens makes it possible to detach actions (for
example verify email) from a user session, which has a number of benefits.
More will come in future 3.x releases and by the end of the year we aim to
fully support replicating Keycloak cross multiple data centers.
Authorization Service improvements
There's been a lot of work done to the authorization services in this
release. Way to many to list here so check out JIRA
We've introduced new QuickStarts with the aim to make it even simpler for
you to get started securing your applications and services with Keycloak.
The QuickStarts have proper tests as well, which can serve as a reference
on how to tests your own applications and services secured with Keycloak.
Check out the new QuickStarts in the keycloak-quickstarts GitHub repository
Upgraded AngularJS and JQuery
We've upgraded the versions we use of AngularJS and JQuery as there where a
number of known vulnerabilities. We're fairly certain neither of the known
vulnerabilities affect Keycloak, but to be on the safe side we decided to
Updated Password Hashing Algorithms
We're still using PBKDF2, but we've added support for SHA256 and SHA512.
PBKDF2 is SHA256 is now used by default.
Spring Boot QuickStarter
We've added a new Spring Boot QuickStarter that makes it super simple to
get started securing your Spring Boot applications. For more details check
out the blog post about it
- Partial export of realms in the admin console
- Redirect URI rewrite rules for adapters
- Test email settings in the admin console
- Initial access tokens now persisted to the db
The full list of resolved issues is available in JIRA
Before you upgrade remember to backup your database and check the migration
Release candidates are not recommended in production and we do not support
upgrading from release candidates.