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

DevFeed: [Red Hat Single Sign-On in Keynote demo on Red Hat Summit!](<https://devfeed.tech/articles/red-hat-single-sign-on-in-keynote-demo-on-red-hat-summit-31574.md>)

Original publisher: [Read original article](<https://www.keycloak.org/2018/06/red-hat-single-sign-on-in-keynote-demo>)

Author: Marek Posolda

Published: 2018-06-17T00:00:00Z

Content type: article

Language: en

Sources: [Keycloak Blog](<https://devfeed.tech/sources/keycloak-blog.md>)

Topics: [Keycloak](<https://devfeed.tech/topics/keycloak.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [openid](<https://devfeed.tech/topics/openid.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [rdbms](<https://devfeed.tech/topics/rdbms.md>), [Security](<https://devfeed.tech/topics/security.md>), [amazon](<https://devfeed.tech/topics/amazon.md>), [Azure](<https://devfeed.tech/topics/azure.md>)

Tags: [amazon](<https://devfeed.tech/tags/amazon.md>), [azure](<https://devfeed.tech/tags/azure.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [idm](<https://devfeed.tech/tags/idm.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [kerberos](<https://devfeed.tech/tags/kerberos.md>), [keycloak](<https://devfeed.tech/tags/keycloak.md>), [ldap](<https://devfeed.tech/tags/ldap.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [openid-connect](<https://devfeed.tech/tags/openid-connect.md>), [rdbms](<https://devfeed.tech/tags/rdbms.md>), [red-hat-summit](<https://devfeed.tech/tags/red-hat-summit.md>), [replication](<https://devfeed.tech/tags/replication.md>), [saml](<https://devfeed.tech/tags/saml.md>), [security](<https://devfeed.tech/tags/security.md>), [sso](<https://devfeed.tech/tags/sso.md>)

## AI overview

This article describes a Red Hat Summit keynote demo using Red Hat Single Sign-On, based on Keycloak, to authenticate a mobile game deployed across Azure, Amazon, and a private cloud. It explains why independent instances with separate databases and caches create limitations for failover, session visibility, user changes, and security, motivating a replicated setup.

## Source excerpt

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 failove