Keycloakで実用的なリバースプロキシ型構成を構築してみよう：Keycloak超入門（7）（4/4 ページ）

[和田広之, 相田洋志, 田村広平, 上田直樹，野村総合研究所／野村総合研究所／フリーランス／株式会社リック]

動作確認

　設定の確認が完了したら、動作確認をしてみましょう。「連携先アプリ1」（https://app1.example.com/）にアクセスします。ログイン画面が表示されたら、「連携アプリ1の管理者」であり、「連携アプリ2の一般ユーザー」である「user001」でログインしてみましょう（画面6）。

画面6　「連携先アプリ1」に「user001」でログイン

　認証が成功すると、「連携アプリ1」のコンテンツが表示されます（画面7）。コンテンツには、HTTPリクエストの情報がJSON形式で表示されます。プレフィックスに「oidc_claim_」とある項目が、mod_auth_openidcが追加したHTTPヘッダ情報になります。mod_auth_openidcは、Keycloakから取得したユーザー情報（Userinfo）を基に、HTTPヘッダ情報を生成しています。特に注目していただきたいのが、「クライアント設定（マッパー）」（前出の画面3）で設定した内容が、「oidc_claim_role」となり、「app2.user, app1.admin」が連携されているところです。

画面7　「連携先アプリ1」に「user001」でログイン後

　続いて、ブラウザを閉じずに、「連携先アプリ1（管理者ロール必要）」(https://app1.example.com/admin/)にアクセスします。「user001」には、「管理者ロール（app1.admin）」が付いているので、アクセスできます（画面8）。

画面8　「連携先アプリ1(管理者ロール必要)」に「user001」でアクセス

　ブラウザを閉じずに、「連携先アプリ2」（https://app2.example.com/）にアクセスします。ログインを求められずに、コンテンツが表示されます（画面9）。

画面9　「連携先アプリ2」に「user001」でアクセス

　さらに、ブラウザを閉じずに「連携先アプリ2（管理者ロール必要）」（https://app2.example.com/admin/）にアクセスします。「user001」には、「管理者ロール（app2.admin）」が付いていないので、「401 Unauthorized」エラーとなります（画面10）。

画面10　「連携先アプリ2（管理者ロール必要）」に「user001」でアクセス

　再度、「連携先アプリ1」（https://app1.example.com/）にアクセスします。再ログインを求められずに、アクセスができました（画面11）。

画面11　「連携先アプリ1」に「user001」で再アクセス

　次は、「連携先アプリ1（ログアウト）」（https://app1.example.com/oidc-redirect/?logout=https://app1.example.com/）にアクセスします。ログアウト処理が実行され、「連携先アプリ1」（https://app1.example.com/）にリダイレクトされ、ログイン画面が表示されました（画面12）。

画面12　「連携先アプリ1（ログアウト）」にアクセス

　なお、クエリパラメーターの「logout」には、ログアウト完了後のリダイレクト先URLを任意に指定可能です。ただし、Keycloak側にセキュリティ設定が施されており、リダイレクト先には制限がかかっているので、リダイレクト先URLを任意に指定したい場合には、Keycloakクライアント設定の「Valid Redirect URLs」にリダイレクト先URLを適切に設定してください。

　そして、「連携先アプリ2」（https://app2.example.com/）に対しても、ログアウトが完了しているかどうかを確かめるためにアクセスしてみます。ログイン画面が表示されました（画面13）。

画面13　ログアウト後、「連携先アプリ2」にアクセス

　ちなみに、未認証状態で「連携先アプリ2（認証不要）」（https://app1.example.com/no_auth/）にアクセスした場合は、プレフィックスに「oidc_claim_」とあるmod_auth_openidcが連携したHTTPヘッダ情報が付いていないことが確認できます（画面14）。

画面14　「連携先アプリ2（認証不要）」にアクセス

　このように、「連携先アプリ1」と「連携先アプリ2」との間でシングルサインオンができていることを確認できました。ここでは省略しますが、ロール条件が異なる「user002」のユーザーでも、シングルサインオン動作を試してみてください。

まとめ

　以上のように、Keycloakのリバースプロキシ型構成により、標準的な認証／認可プロトコルに非対応なアプリに対しても、簡単にシングルサインオンを実現することが可能です。実際には、連携アプリ側に、HTTPヘッダ情報から個人を特定し、セッション情報を生成するといったカスタマイズが必要になりますが、実用性が高い構成であることはご理解いただけたと思います。

　また、今回構築したものは、Keycloakの基本構成一式でもあるので、その他の設定の動作もぜひ確認してみてください。

　なお、現在、非推奨となっているKeycloak公式の「Security Proxy」ですが、代替となる新プロダクト「keycloak-gatekeeper」がリリース予定です。Go言語による実装で、軽量で使いやすそうです。

• keycloak/keycloak-gatekeeper

　次回は、バージョン3系から、大きく強化されているKeycloakの認可機能（Authorization Services）について、詳細に解説します。

筆者紹介

和田 広之（わだ ひろゆき）

野村総合研究所のオープンソースサポートサービス「OpenStandia」で、オープンソースのサポートや製品開発を担当。

• ［連載］OSSによるアイデンティティ管理

Twitter: @wadahiro

筆者紹介

相田 洋志（あいだ ひろし）

野村総合研究所のオープンソースサポートサービス「OpenStandia」で、オープンソースの導入支援やプロジェクト推進を担当。

• OpenStandia Webサイト
• Keycloak日本語ドキュメント

Twitter: @daian183

筆者紹介

田村 広平（たむら こうへい）

野村総合研究所のオープンソースサポートサービス「OpenStandia」で、OpenAMやKeycloakを中心としたOSSの研究開発・テクニカルサポートを担当。

• ［連載］OSSによるアイデンティティ管理
• ［「第6回OpenAMコンソーシアムセミナー」リポート］認証の最新動向と、OpenAMの適用事例を探る

Twitter: @tamura__246

筆者紹介

上田 直樹（うえだ なおき）

野村総合研究所のオープンソースサポートサービス「OpenStandia」で、OpenAMやKeycloakを中心としたOSSの研究開発・導入支援を担当。

Twitter: @naoki_dx_xb