Keycloak session at Red Hat Summit and DevNation

When securing applications and services there are a lot of challenges you will encounter. Most of these are applicable to you both if you are developing new applications or if you already have existing security solutions in place.

Challenges you'll encounter include:

• Keeping user passwords safe
• Single-Sign On/Out
• Multi-factor authentication
• Social logins
• Mobile devices
• Public APIs
• Managing users, permissions and sessions
• Integrating with existing infrastructure such as LDAP server
• Integrating with partners solutions

In the Keycloak session available to both Summit and DevNation attendees we'll talk about how it doesn't have to be hard to solve these challenges. In fact it can be quite simple by using Keycloak, an open source Identity and Access Management solution from Red Hat JBoss. We'll show how Keycloak can be used to secure a modern architecture, including HTML5 applications, mobile applications and RESTful services. We'll also show how you can leverage the integration features provided by Keycloak to integrate with existing security infrastructure and partners.

Securing Microservices

In a traditional multi-tiered architecture like the one shown in the picture below a server-side web tier deals with authenticating the user by calling out to a relational database or an LDAP server. An HTTP session is then created containing the required authentication and user details. The security context is propagated between the tiers within the application server so there's no need to re-authenticate the user.

With a microservice architecture the server-side web application is gone, instead we have HTML5 and mobile applications on the client side. The applications invoke multiple services, which may in turn call other services. In this architecture there's no longer a single layer that can deal with authentication and usually it's stateless as well so there's no HTTP session.

As microservices is all about having many smaller services each that deal with one distinct task the obvious solution to security is an authentication and authorization service. This is where Keycloak and OpenID Connect comes to the rescue. Keycloak provides the service you need to secure micro services.

The first step to securing micro services is authenticating the user. This is done by adding the Keycloak JavaScript adapter to your HTML5 application. For mobile applications there's a Keycloak Cordova adapter, but there's also native support though the AeroGear project.

In an HTML5 application you just need to add a login button and that's pretty much it. When the user clicks the login button the users browser is redirected to the login screen on the Keycloak server. The user then authenticates with the Keycloak server. As the authentication is done by the Keycloak server and not your application it's easy to add support for multi-factor authentication or social logins without having to change anything in your application.

Once the user is authenticated, Keycloak gives the application a token. The token contains details about the user as well as permissions the user has.

The second step in securing micro services is to secure them. Again, with Keycloak this is easy to do with our adapters. We've got JavaEE adapters, NodeJS adapters and are planning to adding more in the future. If we don't have an adapter it's also relatively easy to verify the tokens yourself. A token is basically just a signed JSON document and can be verified by the services itself or by invoking the Keycloak server.

If a service needs to invoke another service it can pass on the token it received, which will invoke the other service with the users permissions. Soon we'll add support for services to authenticate directly with Keycloak to be able to invoke other services with their own permissions, not just on behalf of users.

For more details about OpenID Connect you can look at the OpenID Connect website, but the nice thing is with Keycloak you don't really need to know the low level details so it's completely optional. As an alternative just go straight to the Keycloak website, download the server and adapters, and check out our documentation and many examples.

Keycloak 1.2.0.Final released

No major changes since 1.2.0.CR1 only some minor bug fixes.

For full details see JIRA and to download go to SourceForge.

Distribution changes

We're making some changes to how Keycloak is distributed. Some changes already arrived in 1.2.0, while others will come in 1.3.0. In this post I'll explain what changes we're making and why we're doing it.

Standalone will be the default download of the Keycloak server and will be the recommended option for production and also for non-JavaEE developers. While the appliance was built on the full WildFly application server, the new standalone download will be based on WildFly Core. This will provide a much smaller download and also reduce the footprint of the server.

For JavaEE developers we'll also provide an option to install Keycloak server into an existing WildFly application server. This download is not recommended for production. It will only be possible to install a release off Keycloak server onto one specific WildFly version.

These changes doesn't not affect adapters. Adapters will still be available for JBoss AS7, several versions of WildFly, EAP, Tomcat, Jetty and more.

There are a few reasons why we're going away from the WAR option:

• Compatibility - We can focus on providing features instead of spending time trying to get things to work on multiple containers.
• Testing - Again, we can focus on testing features rather than testing multiple containers.
• WildFly features - We believe WildFly is the best container and it provides a lot of features other containers don't (for example modules, JBoss CLI, patching).
• Integration - By only integrating with one container we can provide a single way of doing things. Some features are not feasible to add to multiple containers, for example authenticating clients with SSL certificates.

Persistent grants in Keycloak

In Keycloak versions before 1.2.0.CR1, we had two separate entities representing client applications. These were Applications, which didn't require consent from user after authentication and OAuth Clients, where the consent was always required.

In Keycloak 1.2.0.CR1 we simplified this and we merged both Applications and OAuth clients to single Client entity, which has on/off configuration switch in Keycloak admin console specifying if consent should be required or not.

When consent is not required from the user, then after user authenticates, the client application will automatically receive access token with all the personal info and permissions of the user. However if consent is required, Keycloak will display consent screen where user needs to confirm all the permissions required by particular Client.

From this release, the granted consents are persistent. This means that user doesn't need to confirm consent for particular client more times. Also each user has possibility to see all the available Client applications in Keycloak Account management and see:

• Permissions he has for particular application
• Granted personal info to particular application
• Granted permissions for particular application

He can also revoke previously granted consent, so next time he authenticates to the application, the consent screen will be shown again.

Also it's possible to view and manage consents from Keycloak admin console. Admin can see the available consents for every user and he can revoke them.

Keycloak 1.2.0.CR1 Released

We've just released Keycloak 1.2.0.CR1. As usual this feature brings some great new features. This time around there's also some fairly big changes.

Distribution changes

Keycloak is now available in 3 downloads. Standalone, overlay and demo bundle. The standalone download is aimed at production and non-JavaEE developers and provides a standalone Keycloak server. Overlay is mainly aimed at JavaEE developers that want to add Keycloak to an existing WildFly 8.2.0.Final (or EAP 6.4.0.GA) installation. Finally the demo bundle is aimed at early adapters and contains WildFly with Keycloak as well as all documentation and examples.

Theme changes

We've updated the look and feel of the admin console, login pages and account management to better match PatternFly. This provides a better integration between Keycloak and other JBoss projects.

Client changes

In previous versions Keycloak had applications and oauth clients. The main difference between the two was that oauth clients required consent from the user. These have been combined into a single client with an option to require consent or not.

New features

• Token mapping - Through token mapping it's possible to pull in additional information from brokered identity providers
• Store and retrieve external token - It's now possible to store the token retrieved from brokered identity providers. Clients can retrieve this if they need to invoke services secured by the external identity provider.
• Persist and manage consents - When a user consents access to a client the consents are now saved. Users can also view and manage consents given to clients through the account management console.
• Password Policies - Through password policies it's now possible to prevent re-use of previous passwords, require users to regularly update their password and also provide a regular expression for required password format.
• HttpClient SPI - The introduction of a HttpClient SPI makes it possible to configure the HTTP connections initiated by Keycloak. For example to provide a trust store.
• KeycloakContext - KeycloakContext is exposed through KeycloakSession and gives providers access to HTTP headers, cookies, query parameters, etc.
• Logging Updates - The JBoss Logging event listener is now enabled by default for new realms. This makes it easier to view debug log information for login events.
• Spring Security Adapter preview - We now have a Spring Security Adapter. There's is no documentation and we haven't tested it thoroughly so consider this a preview.