検索
連載

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

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

Share
Tweet
LINE
Hatena
「Keycloak超入門」のインデックス

連載目次

はじめに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図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からトークンを受け取り、保護されたリソースへのアクセスを許可します。


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

       | 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る