レッドハットサミットの基調講演デモにおけるRed Hat Single Sign-On！
2018年6月17日 Marek Posolda 著
レッドハットサミットは、年間で最も重要なイベントの1つです。多くのギーク、レッドハットの従業員、そして顧客が、出会い、新しいことを学び、多くの興味深いプレゼンテーションやトレーニングに参加する絶好の機会を得ます。今年のサミットでは、KeycloakとRed Hat SSOのみに焦点を当てたブレイクアウトセッションがいくつかありました。詳細については、こちらのブログ記事をご覧ください。
レッドハットサミットの最も重要な部分の1つは、今後の主要な要点と戦略を示す基調講演デモです。通常、それらにはレッドハットが使用する最も興味深いテクノロジーのデモも含まれています。
木曜日の午前中の基調講演では、3つのクラウド（Azure、Amazon、プライベート）によるハイブリッドクラウドの動作を示すこちらのデモがありました！多くのテクノロジーと興味深いプロジェクトが関与していました。中でも、Red Hat JBoss Data Grid (JDG)、OpenWhisk、またはGluster FSなどを挙げることができます。RH-SSO（Keycloakプロジェクトに基づくRed Hat製品）も光栄にも使用されました。
Red Hat SSO のセットアップ詳細
デモのフロントエンドはシンプルなモバイルゲームでした。RH-SSOは、モバイルゲームへのユーザー認証の最初の段階で使用されました。各参加者は自分で試す機会がありました。合計で、ゲームのプレイヤーは1200人でした。
フロントにロードバランサーがあり、すべてのユーザーは自動的に3つのクラウドのいずれかに転送されました。モバイルアプリケーションは、RH-SSOと通信するためにRH-SSO Javascript adapter (keycloak.js) を使用しました。
Javascriptアプリケーションでは、OpenID Connectログインフロー全体がブラウザ内で発生するため、スティッキーセッションに依存できます。したがって、Javascriptアダプターが使用されているため、「簡単な」セットアップを行い、3つのクラウドすべてのRH-SSOインスタンスを互いに独立させ、それぞれが別々のRDBMSおよびInfinispanキャッシュを使用するようにすることができると考えるかもしれません。そのようなセットアップがどのように見えるかの詳細については、以下の画像をご覧ください： 
このセットアップでは、すべてのクラウドは、自身で作成されたユーザーとセッションのみを認識します。これはスティッキーセッションでは問題ありませんが、3つのクラウドのいずれかが破損/削除された場合のフェイルオーバーシナリオでは機能しません。他にも問題があります。たとえば、管理者とユーザーは、特定のクラウドで作成されたセッションのみを表示します。潜在的なセキュリティの問題もあります。たとえば、管理者が1つのクラウドでユーザーを無効にすると、ユーザーへの変更が他のクラウドに伝播されないため、ユーザーは他のクラウドでは引き続き有効になります。
したがって、レプリケーションを認識する、より適切なセットアップを示したいと考えました。また、デモの一部はフェイルオーバーを実演していたためでもあります。3つのクラウドの1つ（Amazon）が停止され、以前にAmazonにログインしていたユーザーは、残りの2つのクラウドのいずれかにリダイレクトされました。ポイントは、エンドユーザーが変更を認識できないようにすることでした。したがって、以前にAmazonにログインしたユーザーは、Azureまたはプライベートクラウドでトークンを更新できる必要があります。これは、データ（ユーザー、ユーザーセッション、キャッシュの両方）が3つのクラウドすべてを認識する必要があることを意味しました。
Keycloak 3.Xでは、データセンター間でデータをレプリケートするために外部JDGサーバーを使用するクロスデータセンター（クロスサイト）セットアップのサポートを追加しました（RH-SSO 7.2の技術プレビュー）。デモでは、まさにこのセットアップを使用していました。各サイトにはJDGサーバーがあり、3つのサイトすべてがこれらのJDGサーバーを介して相互に通信します。これは標準的なJDG Cross-DCセットアップです。デモの様子については、以下の図をご覧ください： 
JDGサーバーは、デモ中、RH-SSOの目的のためだけでなく、デモの他の部分の目的のためにも使用されました。詳細については、Sebastian ŁaskawiecによるJDGセットアップブログで説明されています。JDGサーバーはASYNCバックアップでセットアップされており、より効果的であり、モバイルアプリケーションがkeycloak.jsアダプターを使用していたという事実により、デモの目的には完全に適していました。詳細については、RH-SSOドキュメントをご覧ください。
Red Hat SSO のカスタマイズ
RH-SSOは、標準のRH-SSO OpenShiftイメージを使用していました。Cross-DCセットアップの場合、RHSSOドキュメントで説明されているように構成変更を行う必要がありました。他にもいくつかのカスタマイズが行われました。
JDGユーザーストレージ
RH-SSO Cross-DCセットアップは現在、レプリケートされたRDBMSとレプリケートされたJDGサーバーの両方を必要とします。デモの準備中に、OpenShiftでクラスター化されたRDBMSを3つのクラウドすべてにレプリケートして使用することは、非常に簡単なことではないことがわかりました。
幸いなことに、RH-SSOは高度にカスタマイズ可能なプラットフォームであり、とりわけ、サポートされているユーザーストレージSPIを提供し、顧客がRH-SSOユーザーのために独自のストレージをプラグインできるようにします。そのため、レプリケートされたRDBMSのセットアップの代わりに、カスタムJDGユーザーストレージを作成しました。したがって、サンプルレルムのユーザーは、RDBMSデータベースの代わりにJDG内に保存されました。
学んだ教訓は、Keycloak/RH-SSO Cross-DCセットアップを管理者にとってよりシンプルにしたいということです。そのため、レプリケートされたRDBMSの必要性を完全に取り除き、代わりにすべてのレルムとユーザーメタデータをJDG内に保存することを検討しています。したがって、レプリケートされたJDGのみがCross-DCセットアップの要件になります。
その他のカスタマイズ
デモの目的のために、カスタムログインテーマを作成しました。また、メールアドレスのみでユーザー登録を可能にするメールのみの認証機能も作成しました。これは明らかにセキュリティは高くありませんが、例としては非常に優れています。基調講演のユーザーは、Google Identity ProviderまたはRed Hat Developers OpenID Connect Identity Providerでログインすることもでき、これらのサービスにすでにアカウントを持っているユーザーにとって役立ちました。 
これらのすべてを実際に試してみたい場合は、Githubのデモプロジェクトをチェックアウトして、独自のOpenShiftクラスターにデプロイしてみてください！3つのクラウドをお持ちの場合は、さらに最適です！基調講演デモで使用したセットアップを正確に試すために、JDGを含む完全なセットアップを試すことができます。