Yes, it can be re-visited now. I'd suggest creating a new thread about it
on keycloak-dev. It would have to be contributed by the community though as
we don't have time to work in it ourselves at the moment.
On 3 July 2017 at 03:58, Dmitry Telegin <mitya(a)cargosoft.ru> wrote:
Kudos for the team, you've done a good job!
Stian, remember we've been discussing the hypothetical Admin Resource SPI
last time, you've said:
One issue with introducing admin resource spi now is that it would have to
be reworked once we rework how permissions are done.
Can we consider this refactoring complete or close to completion? If yes,
should we revisit the Admin Resource SPI topic?
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>
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.
keycloak-dev mailing list