Mostly a bunch of bug fixes that we needed to push out for users. We’re still pretty focused on performance and hope that Beta 4 will allow Keycloak to run in a cluster with some caching capabilities. See keycloak.org for links on downloading, docs, and jira release notes.
May 29, 2014
Keycloak Beta-1 has been released! We’re edging closer to 1.0! Please visit the Keycloak website for links to documentation and downloads. A lot of hard work the last few months by Stian, Marek, myself and other contributors to bring you loads of new features and improvements:
- LDAP/Active Directory integration built on Picketlink. Thanks Marek!
- User Session management – can now view login IP address and which applications and oauth clients have open tokens. Works with any type of app too. Can view and manage sessions through user account pages or admin console
- Audit log for important events. Integration with admin console and ability to receive emails on certain events.
- Account log viewable in user account management pages
- Export database. Allows you to export a full dump of keycloak database into an encrypted file. Will help out tremendously to migrate between Keycloak versions.
- Authentication SPI. Allows you to plug in different mechanisms to retrieve and authenticate users.
- Theme support for the admin console and any sent email.
- Per-realm admin console. You can now designate a user within a realm that is an admin of that realm.
- Documented the Admin REST API finally. (Docs still kinda suck here)
- CORS support for Admin REST API
- Support for relative URLs when configuring admin console
- Server configuration file
- Social Only Logins
- Installed application adapter
- Expanded the number of example projects
What’s next? This is the last major feature release of Keycloak. We will now be focusing on performance, clustering, security audits, testing, documentation, and usability for the next few releases. We hope to release 1.0 Final sometime in July.
March 12, 2014
Another big feature release for Keycloak. As usual, go to keycloak.org 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
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.
January 24, 2013
Resteasy 3.0-beta-2 has been released. Follow the links from our main jboss.org page to download and view the documentation. Here are the highlights:
- Added a new ResteasyClientBuilder class to make it easier to create HTTPS/SSL connections on the client side
- Extensive work on OAuth 2.0 support including tight AS7 integration.
- Turn an existing servlet-form-auth-based web application into an OAuth 2.0 provider.
- Provide Distributed Single-Sign-On (SSO) from a central authentication server. Log in once, and you can securely access any browser-based app configured to work in the domain.
- Provide Distributed Logout. Following one link from any application can log you out of all your distributed applications configured to use SSO.
- Web apps can interact securely with any remote restful service by forwarding access tokens through the standard Authorization header.
- Access tokens are digitally signed by the oauth2 framework and can be used to access any service configured to work in the domain. The tokens contain both identity and role mapping information. Because they are digitally signed, there’s no need to overload the central authentication server with each request to verify identity and to determine permissions.
What’s next for Resteasy? Next release I’ll be focusing on getting it up to date with the latest JAX-RS 2.0 snapshot. I also have to get started on my O’Reilly book.
November 15, 2012
For those of you you didn’t know, OAuth2 has now gone to the RFC phase at IETF. I have a lot of mixed feeling about it now that I’ve read it a few times and am starting to write code around it. Firstly, I think the spec is very solid, well thought out, and built on top of ideas and solutions that have been around for while. Unfortunately though, ,OAuth 2 is not a security solution in and of itself. It isnt even a complete protocol. It is a framework for building security protocols and solutions. This holdstrue with frameworks stating they support OAuth2. They can’t support Oauth2, because Oauth2 is incomplete. Any framework with OAuth2 support will require you to write a bunch of integration code unless they are targeting a specific provider like Google or Facebook for example.
You may not need OAuth
For all the noobs writing RESTful services, they think, if I’m doing REST, I need REST security. Given that I do REST talks every once in awhile, often I see the perception that OAuth == REST security. So, before you say “I need OAuth”, actually understand your security needs.
- Does your app already manage user logins and authorization? Are your clients only going to interact with this app? If so, you don’t need OAuth. From the Java EE Servlet perspective, you just need Basic, Digest, Client-Cert, or FORM authentication with user-role mapping declarations.
- Do you *not* need the ability to grant permission to a thirdparty to access your data? Then you don’t need OAuth
I may need OAuth
- Do you want a central authentication server that manages authentication and authorization for all your web apps? Then you may need OAuth
- Do you want the allow users to grant temporary permission for third parties to access services on behalf of them? Then you may need OAuth
Why is OAuth Incomplete?
- OAuth2 does not define how a user authenticates. If you are looking for OAuth to be an SSO solution, your code-driven clients will have to have specific integration with each and every auth server to pass credentials. OAuth2 does not define what credentials should be passed around. It does not define how those credentials are transmitted.
- OAuth2 only suggests an app auth method. After user authenticate, the app must turn an auth code into an access token. OAuth2 does not require a specific authentication mechanism for this, but does require authentication.
- OAuth2 doesn’t define the scope token or access token format. The OAuth 2 protocol is all about acquiring a temporary access token with a defined scope. The scope defines what a client is allowed to do. Each target service will need to understand specific scope or access token formats in order to grant specific permissions.
- OAuth does not define how third-party authenticates. After obtaining an access token, OAuth does not require any specific mechanism to authenticate a third-party to the target resource. It does offer suggestions, specifically the Bearer and MAC token RFCs.
So what does this mean? Writing generic OAuth2 support for a framework is not possible. Users will have to implement integration code for each OAuth2-compliant auth-server they want to integrate with both on the client side of things (i.e. JAX-RS Client) or the application side (your web apps). While it may be possible to provide some helper code, IMO, you’d be better off just coding the entire thing yourself as, IMO, you’ll understand the protocol better.
How will Resteasy support OAuth 2?
Resteasy will focus on full solutions rather than helper classes. I’m not convinced there’s enough helper code we could write that would add enough value for users to build on top on. Instead we’ll do the following:
- Resteasy token formats. We will define our own token formats that map well to JAX-RS and Java EE environments.
- We will define specific authentication protocols for user authentication and protocols for auth code to access code conversion.
- We will provide or own IDP/Auth-server solution. This will be a lightweight solution with simple file-based persistence.
- We will write specific end-to-end solutions to things like Google OAuth APIs and Picketlink and any other OAuth2 provider that is really popular
- For each OAuth2 provider, we will have a JAX-RS only solution so you can run in any environment you want. We will also have specific AS7 integration so you that you can use web.xml role mappings as well as Subject propagation to other Java EE component layers.