Wednesday, 12 March 2014

Keycloak Alpha 3 Released

Another big feature release for Keycloak.  As usual, go to to find documentation and download links.  Here are the highlights of Alpha 3:
  • Minimal support for OpenID Connect.  Claims like email, full name, etc. can now be transmitted and viewed with IDToken passed after login.

  • Configurable allowed claims.  What identity claims are made in id and access tokens can be configured per application or oauth client within the admin console

  • Remote logout and session stats available from management console

  • Refresh token support

  • Not before revocation policy.  You can set it per realm, oauth client, or application.  Policies are pushed to applications that have an admin url

  • Fine grain admin console permissions and roles.  You can now specify which realms a master user is allowed to create, view, or edit.  An awesome side effect of this is that if you enable registration in the master admin realm and set a default global role of create only, keycloak can become a SaaS for SSO.

  • Installed Application feature to support non-browser applications that want to use Keycloak

  • You can now add social network links through account management

What's next?

Our next release will be Beta-1 and will be our last big feature release.  One of the features we want to add is support for using an existing LDAP/Active Directory server.  We're going to take a look at Picketlink IDM API for this.  We also need more fine grain support for importing and exporting various pieces of the keycloak database.  That's minimally what we want to get in.  We're looking at a May timeframe for this release as in April many of us will be busy with Red Hat Summit.


  1. great. will give it a go.

  2. nice one! Have been playing all night with alpha2, tomorrow I'll spin up an alpha3 :-)

  3. G.L. Srinivasan10 April 2014 at 08:37

    Dear Bill,
    We are evaluating KeyCloak for SSO and authnorization services for our company. Oe suggestion wrt LDAP connectivity is this. Let us say an LDAP record of a user has been created using LDAP Admin conosle. All updates to LDAP are done less frequently and using Administrators in the Admin console. We can use REST "Get " to read LDAP records of users where each remote CRUD method of the RESTFUL class can be implemented to encapsulate OPENLDAP API
    calls to register with LDAP server and retrieve required LDAPrecords. for Authentication purposes. We can use smiliar method calls for other CRUD operations. We can circumvent the use of PicketLInk api calls.

  4. You should ask this question on our user or dev list. We have not released LDAP integration yet, but have built some support for it within our master branch (using Picketlink IDM). We're thinking of implementing a Sync API to/from Keycloak and LDAP. It would be great to get your insight on what you think the best way to implement LDAP integration would be. Let's take this to the DEV list

  5. A. Kevin Bailey22 May 2014 at 15:34

    Looks like there is an error in the org.keycloak.representations.AccessToken field mappings when the object is returned by keycloakSecurityContext.getToken(). The "id" field and the "subject" field seem to be swapped.

  6. A. Kevin Bailey22 May 2014 at 15:35

    I mean the values seem to be swapped.


Please only add comments directly associated with the post. For general questions use the Keycloak user mailing list.