Monday, 2 March 2015

Keycloak clustering: part 2 - Clustering support for applications

Previous blog post mentioned our support for clustered Keycloak server. From 1.1.0.Final, we have also clustering support for applications secured by Keycloak! All common scenarios like SSO, Single sign-out or propagation of global admin events should be cluster-safe now.

HTTP Session or cookie

By default, the servlet web application secured by Keycloak uses HTTP session to store information about authenticated user account. From Keycloak 1.1.0.Final, this info could be replicated across cluster and your application will safely survive failover of some cluster node. However if you don't need or don't want to use HTTP Session, you may alternatively save all info about authenticated account into cookie. In this case, no HTTP Session replication will happen among application cluster nodes. This is useful especially for stateless applications.

Backend requests optimization

Keycloak has support for OpenID Connect protocol, which is used for communication between Keycloak server and applications. The communication happens by "front" channel (browser redirects), but also by "backend" channel, when Keycloak server and application server sends messages directly to each other without involving web browser. We added possibility that "backend" channel communication is optimized and Keycloak server and application server communicates directly with each other without proxying requests through loadbalancer. This is especially useful when Keycloak and applications are deployed on same host. For example when you have cluster nodes "node1", "node2" and some HTTP Session is handled on "node2", the application will communicate by backend channel with Keycloak server on "node2" as well.

Nodes autodiscovery

In some cases admin may want to propagate some global "admin" tasks triggered from Keycloak admin console to all registered cluster nodes. For example push new notBefore for realm, or logout all users from all applications on all cluster nodes. In this case Keycloak should be aware of all application cluster nodes, so it could send event to all of them. To achieve this, we support auto-discovery mechanism.

Once new application node joins cluster, it sends registration request to Keycloak server. The request may be re-sent to Keycloak in configured periodic intervals. Admin can monitor in Keycloak admin console all registered application nodes, which are actually auto-registered and send "alive" request to them. He can also manually register or unregister nodes if don't want to rely on auto-discovery mechanism. When admin triggers "global" event, like forced logout of all users, it will be sent to all registered application cluster nodes.

For more info, check our documentation and try it in action!

Wednesday, 4 February 2015

Keycloak clustering - Improving availability and scalability withInfinispan

One of the major features introduced in Keycloak 1.1.0.Final is improved clustering capabilities. Through clustering Keycloak you can provide high availability and scalability, which is obviously important if you rely on Keycloak to login to critical applications.

We could have chosen to build this clustering capability from the ground, but we're in the business of developing an identity and access management solution not a clustering solution. Second option could have been the excellent JGroups, but that's still low level stuff though. Luckily at JBoss we have no shortage of middleware and we obviously have a solution for this. Unless you've been living under a stone the last few years you should have heard about it, it's called Infinispan!

Infinispan is a distributed in-memory key/value data grid and cache. It's a mature project and loaded with features, which fits our needs perfectly.

In Keycloak we have 3 different types of data:
  • Realm and application meta-data
  • Users, credentials and role-mappings
  • User sessions

Each have different needs when it comes to clustering.

Realm and application meta-data are frequently read, but unless your sysadmin really loves reconfiguring things, not so frequently changed. There's also only so many realms and applications in an organization so the size is limited. This mean we can save it all in a database and cache it all in memory as its access. If a change is made it's written directly to the database. To make sure all nodes retrieve the updates we use an invalidation cache. An invalidation cache simply sends a message to the cluster that invalidates an entry in the cache. Next time the data is requested it won't be in the cache and the updated version is loaded from the database. This is beneficial for us compared to a replicated cache as it doesn't send sensitive data throughout the cluster and also reduces network traffic.

Users are by default handled the same way as realm and app meta-data. It's good practice to change your password once in a while, but certainly not every time you  log in! So that means users are also frequently read, but not so frequently changed. There can be a lot more users than realms though, so we set a maximum number of users that are cached. This results in active users being held in memory, while inactive users are purged from memory.

User sessions are very different as they are frequently updated. Every time a user logs in a new user session is created. We also have a mechanism to expire idle sessions, which results in every time a user session is accessed it's also updated. If we stored user sessions in a database and used an invalidation cache performance and scalability wouldn't be very good. Also, user sessions are not critical data so doesn't have to be persisted in a database. In the worst case scenario if a user session is lost a user has to log back in. For user sessions we use a distributed cache. This provides good performance as they are not persisted, it provides good scalability as they're split into segments where each node only holds a subset of the sessions in memory. Finally, if you really need higher availability for user sessions we recommend you configure replicating each segment to more than one node rather than persisting the sessions.

Thursday, 29 January 2015

Login to Jenkins with Keycloak

Thanks to Nadeem Mohammad it's now easy to login to your Jenkins server with Keycloak. For more details have a look at Jenkins Wiki and the Youtube demo. The source code is available in our github.

Wednesday, 28 January 2015

Keycloak 1.1.0.Final Released

The Keycloak team is proud to announce the release of Keycloak 1.1.0.Final. Highlights in this release includes:
  • SAML 2.0
  • Clustering
  • Jetty, Tomcat and Fuse adapters
  • HTTP Security Proxy
  • Automatic migration of db schema

We're already started working on features for the next release. Some exiting features coming soon includes:
  • Identity brokering
  • Custom user profiles
  • Kerberos
  • OpenID Connect interop

Tuesday, 16 December 2014

Merry Christmas from the Keycloak team

2014 was the year of Keycloak! At least that was the case for us on the Keycloak team. In January we released the very first alpha of the project. The first stable release wasn't out until September, but in return we added a lot more features as well as reaching a very high level of stability for a 1.0.

Since then we've delivered a number of security and bug fixes for 1.0, while continuing to bake in new exiting features for 1.1. We're planning to do a stable release of 1.1 early in the New Year, which will bring SAML 2, much improved clustering and a number of new application adapters.

Not only have we managed to provide a feature rich and easy to use open source security solution, but we've also managed to build an awesome community around the project. We've had over 5000 downloads, over 2500 commits from 32 contributors and our developer and user mailing lists are very active. Keycloak is already in use in production on a number of projects, in fact some has even used it in production since our first alpha release!

Our road-map for 2015 is not written in stone, but expect at least some of the following features to be delivered in 2015:
  • Custom user profiles - this will let you configure the attributes for a user profile, which should be visible on the registration screen and account management, as well as specify validation

  • Identity Brokering - we're adding support to authenticate with external Identity Providers via OpenID Connect, SAML 2.0 and Kerberos

  • Two-Factor Authentication - currently we only support Google Authenticator or FreeOTP applications for two-factor authentication, but we plan to make it possible to add your own and provide some more out of the box

  • Client Accounts - these will be special user accounts directly linked to a client, allowing a client to access services as itself not just on-behalf of users

  • Client Certificates - support authentication of clients with certificates

  • Client Types - at the moment we have applications and oauth clients, the main difference being oauth clients require users to grant permissions to roles. To simplify the admin console we plan to introduce a single unified view for clients and also introduce new types such as devices

  • Internationalization - internationalization support for login and account management pages

  • SMS - enable SMS to recover passwords, as a 2nd factor authentication mechanism and to be notified about events like login failures

  • OpenID Connect Dynamic Registration -  allows clients to dynamically register with Keycloak. We'll also look at passing the OpenID Connect Interop testing

  • Mapping of users and tokens - custom mapping of user profiles from external identity stores and tokens from external Identity Providers
We also have ideas for some bigger features, but we'll leave those as a surprise for 2015!

Finally, I'd like to wish everyone a Merry Christmas and a Happy New Year.

Wednesday, 5 November 2014

Keycloak 1.1.0 Beta1 Released

Pretty big feature release:
  • SAML 2.0 support.  Keycloak already supports OpenID Connect, but with this release we're also introducing support for SAML 2.0.  We did this by pulling in and building on top of Picketlink's SAML libraries.

  • Vastly improved clustering support.  We've also significantly improved our clustering support, for the server and application adapters. The server can now be configured to use an invalidation cache for realm meta-data and user profiles, while user-sessions can be stored in a distributed cache allowing for both increased scalability and availability. Application adapters can be configured for either sticky-session or stateless if sticky-sessions are not available. We've also added support for nodes to dynamically register with Keycloak to receive for example logout notifications.

  • Adapter multi-tenancy support.  Thanks to Juraci Paixão Kröhling we now have multi-tenancy support in application adapters. His contribution makes it easy to use more than one realm for a single application. It's up to you to decide which realm is used for a request, but this could for example be depending on domain name or context-path. For anyone interested in this feature there's a simple example that shows how to get started.

  • Tomcat 7 Adapter.  A while back Davide Ungari contributed a Tomcat 7 application adapter for Keycloak, but we haven't had time to document, test and make it a supported adapter until now.

What's next?

The next release of Keycloak should see the introduction of more application adapters, with support for JBoss BRMS, JBoss Fuse, UberFire, Hawt.io and Jetty.

For a complete list of all features and fixes for this release check out JIRA.

I'd like to especially thank all external contributors, please keep contributing! For everyone wanting to contribute Keycloak don't hesitate, it's easy to get started and we're here to help if you need any pointers.

Tuesday, 28 October 2014

Keycloak 1.0.3.Final released

Another security and bug fix release in the 1.0 series.

For full details look in JIRA.