Keycloakで外部アイデンティティー・プロバイダーと連携してみよう：Keycloak超入門（5）（1/3 ページ）

本連載では、近年注目されている認証プロトコル「OpenID Connect」をサポートするオープンソースのシングルサインオン（SSO）ソフトウェア「Keycloak」の活用方法を解説していきます。Keycloakは、OAuthやOpenID Connectに対応しており、GoogleやFacebookなどのユーザーを利用したSSOやアクセス制御が簡単に設定できます。

[和田広之, 相田洋志, 田村広平, 上田直樹，野村総合研究所]

連載目次

はじめに

　連載第5回目となる今回からは、野村総合研究所のOSSサポートサービス「OpenStandia」のメンバーが執筆させていただきます。日立製作所の茂木氏が執筆した前回まででは、次のような内容を紹介してもらいました。

• 第1回　マイクロサービス時代のSSOを実現する「Keycloak」とは
• 第2回　サンプルアプリケーションでKeycloakのSSO動作を確認してみよう
• 第3回　Keycloakクライアントアダプターを利用してAPIサービスを構築してみよう
• 第4回　Keycloakのクラスタ環境を構成してみよう

　今回からは数回に分けて、「Keycloak」の機能を幾つか紹介していきます。今回は、GoogleやFacebookなどのSNS（Social Networking Service）のユーザーを、Keycloakと連携するアプリケーションにシングルサインオンさせる方法について説明します。

Webサービスのログイン動向

　最近では、以下の画面1のように、SNSのアカウントを使ってログインできるWebサービスをよく見掛けるようになりました。

画面1　SNSアカウント連携の例（JBossDeveloperのログインページ）

　いつも利用しているSNSのアカウントがあれば、ユーザーは自身の情報をWebサービスごとに個別に登録することなく、簡単にWebサービスを利用できるようになるので、とても便利です。それだけでなく、アカウントを1つに集約できるので、管理が楽になり、IDとパスワードを忘れてしまうといった問題も防止できます。

　Keycloakでは、このような最近よく見掛ける認証方式も簡単に設定できます。これを実現するのが、Keycloakの「アイデンティティー・ブローカー」機能になります。

Keycloakのアイデンティティー・ブローカー機能とは

　アイデンティティー・ブローカーとは、「外部アイデンティティー・プロバイダー」（以下、外部IdP）のアカウントを使用して、Keycloakと連携しているアプリケーションにシングルサインオン（SSO）できるように仲介する機能です（図1）。

図1　外部アイデンティティー・プロバイダー連携

　ただし、ここでいう外部IdPは「SAML」「OAuth」「OpenID Connect」のいずれかのプロトコルに対応し、ユーザーを認証する機能を提供しているサービスのことです。最近の主要なSNSはこの条件を満たしているので、外部IdPとして利用可能です。

　一方、Keycloakと連携するアプリケーションは、これらのプロトコルに対応している必要はありません。Keycloakのアイデンティティー・ブローカー機能が、代わりにこれらのプロトコルを使用し、外部IdPと通信します。以下の図2ように、外部IdPとはOpenID Connectで通信し、連携アプリとはSAMLで通信することもできます。

図2　Keycloakのアイデンティティー・ブローカー機能

　現在、Keycloakでは、主要なSNSを外部IdPとして簡単に設定できるようになっています。Google、Facebook、Twitter、GitHub、LinkedIn、Microsoft、Stack Overflowに関しては、Keycloak管理コンソール内に専用の設定画面があります（画面2）。将来的にはさらなるSNSの追加も計画されています。

画面2　KeycloakがサポートしているSNSを全て設定した場合のログイン画面

　また、Keycloakでは汎用的な設定画面も提供しており、前述のいずれかのプロトコルに対応している外部IdPであれば、連携することができます。例えば、自社で開発したOAuthの認可サーバや、OpenAMのような他のプロダクトがあれば、それを利用することも可能です。

　今回は、外部IdPとしてGoogleを使用したアイデンティティー・ブローカー機能を実際に設定し、動作確認してみます。Googleと連携する際のプロトコルは、OpenID Connectになります。

　ユーザーがKeycloakと連携するアプリケーション（例えば、Spring BootベースのWebアプリケーション）のリソースへアクセスするまでのフローは、以下の図3のようになります。

図3　アイデンティティー・ブローカーを経由したアプリへのアクセス

　使用しているプロトコルによって若干異なりますが、基本的なフローは以下のようになります。

（1）ユーザーは、Keycloakと連携するアプリケーション（以下、連携アプリ）のリソースにアクセスします。

（2）アプリケーションは、ユーザーを認証するためにKeycloakにリダイレクトします。

（3）Keycloakは、ユーザーにログインページを表示します。ログインページには、外部IdPのリストが表示されます。

（4）ユーザーは、IdPのリストからGoogleを選択します。

（5）Keycloakは認証を要求するリクエスト発行し、ユーザーをGoogleにリダイレクトします。

（6）Googleは、ログイン画面を表示します。

（7）ユーザーは、IDとパスワードを入力するなどして、Googleにログインします（認証）。その後、Googleは必要に応じて、Keycloakがユーザーの情報にアクセスすることへの同意をユーザーに求めます（認可）。

（8）認証と認可が成功すると、ユーザーは認証レスポンスとともにKeycloakにリダイレクトされます。通常、このレスポンスには、Keycloakが使用するセキュリティトークンが含まれています。セキュリティトークンは、Googleによって実行された認証を信頼し、そのユーザーに関する情報を取得するために使用されます。

（9）Keycloakは、Googleからのレスポンスが有効かどうかをチェックします。有効であり、ユーザーが存在しない場合はインポートして作成し、既に存在する場合はスキップします。新規ユーザーの場合、Keycloakはユーザーに関する情報がセキュリティトークンに存在していなければ、IdPに問い合わせることがあります。また、ユーザーが既に存在する場合は、KeycloakはIdPから返されたアイデンティティーを既存のアカウントにリンクするように要求することがあります。このステップの最後でKeycloakがユーザーを認証し、要求された連携アプリのリソースにアクセスするために独自のトークンを発行します。

（10）ユーザーがローカル（Keycloak）で認証されると、Keycloakはローカル認証中に既に発行されていたトークンとともに、ユーザーを連携アプリにリダイレクトします。

（11）連携アプリはKeycloakからトークンを受け取り、保護されたリソースへのアクセスを許可します。

　なお、このフローにおける幾つかの動作は、設定で変更できます。例えば、初回ログイン時にユーザーをインポートする、ユーザーが既に存在すればエラーにする、電子メールを使ってアカウントをリンクさせる、といったことが実現できます。