Red Hat

W3C Web Authentication (WebAuthn)

Wednesday, March 06 2019, posted by Stian Thorgersen

W3C Web Authentication (WebAuthn) was recently made an official web standard. This is a great step towards making a safer and simpler authentication experience for users.

Where traditional authentication, such as password and OTP, rely on having shared secrets between the user and the web application, this is not the case with WebAuthn. WebAuthn uses public key-based credentials resulting in the web application not having access to the users secrets anymore. The keys are also unique per web application which eliminates the risk of phishing attacks.

WebAuthn provides a standard protocol for web applications to authenticate via a number of devices through a relatively simple challenge/response. All major browser vendors now have support for WebAuthn and FIDO2, where FIDO2 is the specification that enables the browser to communicate with different hardware devices.

WebAuthn can be used both as a two factor mechanism as well as enable passwordless authentication. There are already an healthy amount of devices that can be used together with WebAuthn. There are a number of security keys like YubiKey, ThinC and Titan. A lot of new laptops also come with built-in fingerprint scanners, and it Android also recently made it possible to use the fingerprint scanners on Android 7+ devices with WebAuthn.

We are of course planning on bringing WebAuthn support to Keycloak in the near future. The team behind webauthn4j has been hard at work greating a quality Java library for WebAuthn and will hopefully soon have an extension to Keycloak ready.

We will first focus on two-factor authentication with WebAuth and as part of this we will bring a number of improvements to Keycloak around two-factor authentication. For more details check the design document.

Later, we will also bring the passwordless experience to Keycloak. This will also introduce Keycloak to the identity first login flows. By asking for the users identity first Keycloak can provide smarter decisions on how to authenticate a user based on the users preferences. For example requesting the user to press the button on their security key instead of asking for a password.


Keycloak 5.0.0 released

Wednesday, March 06 2019

To download the release go to Keycloak downloads.

For details on what is included in the release check out the Release notes. The full list of resolved issues are available in JIRA

Before you upgrade remember to backup your database and check the upgrade guide for anything that may have changed.

Keycloak on Kubernetes

Wednesday, June 27 2018, posted by Stian Thorgersen

If you'd like to get started with using Keycloak on Kubernetes check out this screencast. If you'd rather try it out yourself check out this GitHub repository that contains the instructions as well as all the bits you'll need to reproduce what is shown in the screencast.

Keycloak Cordova Browser Tabs support

Thursday, June 21 2018, posted by Stian Thorgersen

Thanks to gtudan we finally have support for browser tabs for Cordova in our JavaScript adapter. This enables using a system browser tab to do the login flows to Keycloak, which brings better security and also single sign-on and single sign-out to mobile applications secured with Keycloak.

This will be included in Keycloak 4.1.0.Final which will be released soon. In the meantime check this screen-cast to see this in action!

Red Hat Single Sign-On in Keynote demo on Red Hat Summit!

Sunday, June 17 2018, posted by Marek Posolda

Red Hat Summit is one of the most important events during the year. Many geeks, Red Hat employees and customers have great opportunity to meet, learn new things and attend lots of interesting presentations and trainings. During the summit this year, there were few breakout sessions, which were solely about Keycloak and Red Hat SSO. You can take a look at this blogpost for more details.

One of the most important parts of Red Hat Summit are Keynote demos, which show the main bullet points and strategies going forward. Typically they also contain the demos of the most interesting technologies, which Red Hat uses.

On the Thursday morning keynote, there was this demo to show the Hybrid Cloud with 3 clouds (Azure, Amazon, Private) in action! There were many technologies and interesting projects involved. Among others, let's name Red Hat JBoss Data Grid (JDG), OpenWhisk or Gluster FS. The RH-SSO (Red Hat product based on Keycloak project) had a honor to be used as well.

Red Hat SSO setup details

The frontend of the demo was the simple mobile game. RH-SSO was used at the very first stage to authenticate users to the mobile game. Each attendee had an opportunity to try it by yourself. In total, we had 1200 players of the game.

There was loadbalancer up-front and every user was automatically forwarded to one of the 3 clouds. The mobile application used RH-SSO Javascript adapter (keycloak.js) to communicate with RH-SSO.

With Javascript application, whole OpenID Connect login flow happens within browser and hence can rely on sticky session. So since Javascript adapter is used, you may think that we can do just "easy" setup and let the RH-SSO instances across all 3 clouds to be independent of each other and have each of them to use separate RDBMS and infinispan caches. See the image below for what such a setup would look like:

With this setup, every cloud is aware just about the users and sessions created on itself. This is fine with sticky session, but it won’t work for failover scenarios in case if one of the 3 clouds is broken/removed. There are also other issues with it - for example that admins and users see just sessions created on particular cloud. There are also potential security issues. For example when admin disables user on one cloud, user would still be enabled on other clouds as changes to user won’t be propagated to other clouds.

So we rather want to show more proper setup aware of the replication. Also because one part of the demo was showing failover in action. One of the 3 clouds (Amazon) was killed and users, who were previously logged in Amazon, were redirected to one of the remaining 2 clouds. The point was that the end user won't be able to recognize any change. Hence users previously logged in Amazon must be still able to refresh their tokens in Azure or Private cloud. This in turn meant that the data (both users, user sessions and caches) need to be aware of all 3 clouds.

In Keycloak 3.X, we added support for Cross-datacenter (Cross-site) setup with usage of external JDG servers to replicate data among datacenters (tech preview in RH-SSO 7.2). The demo was using exactly this setup. Each site had JDG server and all 3 sites communicate with each other through those JDG servers. This is standard JDG Cross-DC setup. See the picture below for what the demo looked like:

The JDG servers were not used during the demo just for the purpose of the RH-SSO, but also for the purpose of other parts of the demo. The details are described in the JDG setup blog by Sebastian Łaskawiec. The JDG servers were setup with ASYNC backups, which was more effective and was completely fine for the purpose of the demo due the fact that mobile application was using keycloak.js adapter. See RH-SSO docs for more details.

Red Hat SSO customizations

The RH-SSO was using standard RH-SSO openshift image . For Cross-DC setup, we needed to do configuration changes as described in the RHSSO documentation . Also few other customizations were done.

JDG User Storage

RH-SSO Cross-DC setup currently requires both replicated RDBMS and replicated JDG server. When preparing to demo, we figured that using the clustered RDBMS in OpenShift replicated across all 3 clouds, is not very straightforward thing to setup.

Fortunately RH-SSO is highly customizable platform and among other things, it provides supported User Storage SPI , which allows customers to plug their own storage for RH-SSO users. So instead of setup of replicated RDBMS, we created custom JDG User Storage. So users of the example realm were saved inside JDG instead of the RDBMS Database.

Lessons learned is, that we want to make the Keycloak/RH-SSO Cross-DC setup simpler for administrators. Hence we're considering removing the need for replicated RDBMS entirely and instead store all realms and users metadata within JDG. So just replicated JDG would be a requirement for Cross-DC setup.

Other customizations

For the purpose of the demo, we did custom login theme. We also did Email-Only authenticator, which allows to register user just by providing their email address. This is obviously not very secure, but it's pretty neat for the example purpose. Keynote users were also able to login with Google Identity Provider or Red Hat Developers OpenID Connect Identity Provider, which was useful for users, who already had an account in those services.

If you want to try all these things in action, you can try to checkout our Demo Project on Github and deploy it to your own openshift cluster! If you have 3 clouds, even better! You can try the full setup including JDG to try exactly the setup we used during keynote demo.

For older entries go here.