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

本連載では、近年注目されている認証プロトコル「OpenID Connect」をサポートするオープンソースのシングルサインオン（SSO）ソフトウェア「Keycloak」の活用方法を解説していきます。Keycloakと標準的な認証／認可プロトコルに対応したプロキシを組み合わせることで、プロトコル未対応のアプリケーションに対し、安全なシングルサインオン環境を提供できます。

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

連載目次

本稿で紹介したDocker環境は、以下のGitHubで公開しています。すぐに動かすことができますので、こちらもぜひご参照ください。

• https://github.com/openstandia/keycloak-dockerfiles

はじめに

　企業内には、以下のような理由で標準的な認証／認可プロトコルに対応できないケースが存在することもあると思います。

• レガシーなアプリケーションで改修が難しい
• 新規のアプリケーションであってもパッケージの制約で対応が難しい

　 Keycloakは、認証／認可プロトコル対応プロキシと組み合わせることで、上記のようなケースにおいても大きな手間をかけずにシングルサインオン環境を構築できます。

　これを実現するのが、Keycloakの「リバースプロキシ型構成」です。

リバースプロキシ型構成とは

　Keycloakのリバースプロキシ型構成とは、Keycloakと認証／認可プロトコル対応プロキシを組み合わせて構築するシステムアーキテクチャです（図1）。

図1　Keycloakのリバースプロキシ型構成

　この構成にすることで、連携アプリケーション（以下、連携アプリ）が、認証／認可プロトコルに非対応であっても、シングルサインオンできるようになります。また、連携アプリ開発側から見れば、認証／認可プロトコルの専門的な知識が不要で、ライブラリやフレームワークを導入する影響も気にしなくてよいので、アプリ開発に専念できるといったメリットがあり、実用的な構成といえます。

●認証／認可プロトコル対応プロキシのプロダクト紹介

　現在、数多くの認証／認可プロトコル対応のプロキシがリリースされています。以下の表1に有名なプロダクトの一部を紹介します。

プロダクト名	特徴	対応プロトコル	認証セッション管理方式（※）
mod_auth_openidc	Apacheのモジュールで提供されるOpenID Connectベースのプロキシプロダクト。Apacheの基本機能である<Location>や、<VirtualHost>などと組み合わせて設定可能なため、リソースに対する認証必要有無が柔軟に表現できる。また、セッションキャッシュ方式が多種実装されているため、セッション管理に堅牢（けんろう）さを求める場合には、選定上の優位性がある。	OpenID Connect／OAuth 2.0	サーバ・メモリ管理方式／ファイル管理方式／オンメモリDB管理方式（memcacheまたはredis）／クライアント・クッキー管理方式
mod_auth_mellon	Apacheのモジュールで提供されるSAMLベースのプロキシプロダクト。Apacheの基本機能である<Location>や、<VirtualHost>などと組み合わせて設定可能なため、リソースに対する認証必要有無が柔軟に表現できる。SAMLプロトコルの仕様上、IdPとSP間の通信を行わないようにできるため、IdPとSP間にネットワーク制約がある環境下では、選定上の優位性がある。	SAML 2.0	サーバ・メモリ管理方式
Security Proxy	Keycloak公式のOpenID Connectベースのプロキシプロダクト。現在、更新が止まっており、非推奨となっているため、積極的には採用をしにくい状況だが、新たに代替のプロキシプロダクトがリリースされる予定。	OpenID Connect	サーバ・メモリ管理方式
AWS ALB	AWS ELB内に構成されるApplication Load Balancerサービス。2018年5月30日に認証機能が追加された。AWSで構成されるシステムであれば、別途リバースプロキシサーバを用意する必要がなくなるため、選定上の優位性がある。	OpenID Connect	クライアント・クッキー管理方式
表1　認証／認可プロトコル対応プロキシのプロダクト一覧

【※】「認証セッション管理方式」とは、認証／認可プロトコル対応のプロキシが生成する、ユーザー認証セッションを管理する方式を指します。通常、プロキシサーバのメモリ内で管理されるものが多いのですが、この仕様だとプロキシサーバがダウンしてしまうと再認証を求められるケースがあり、注意が必要です。また、中には、シビアな要件にも対応できるように、耐障害性が考えられた方式もあります。

　認証／認可プロトコル対応プロキシのプロダクトは、それぞれ異なった特徴があるため、用途に応じて適切なプロダクトを選択してください。

●リバースプロキシ型構成の認証シーケンス

　使用するプロトコルによって異なりますが、プロトコルが「OpenID Connect」の場合、リバースプロキシ型構成の認証シーケンスは以下のようになります（図2）。

図2　リバースプロキシ型構成の認証シーケンス

（1）ユーザーは、Keycloakと連携するアプリケーション（連携アプリ）のリソースにアクセス（要求）します。
（2）RP（Relying Party）は、ユーザーが未認証であるため、OP（OpenID Provider）へリダイレクトします。
（3）ブラウザは、OPへ認証リクエストを送信します。
（4）OPは、ユーザーへ認証画面を返却します。
（5）ユーザーは、OPへID／パスワードを送信します。
（6）OPは、RPへリダイレクトします。このとき、認可コードがURLクエリに付与されています。
（7）ブラウザは、RPへ認可コードを送信します。
（8）RPは、受信した認可コードをもとに、OPへトークン（アクセストークン／IDトークン）を要求します。
（9）OPは、トークン（アクセストークン／IDトークン）を返却します。
（10）RPは、アクセストークンを基に、OPへユーザー情報を要求します。
（11）OPは、RPへユーザー情報を返却します。
（12）RPは、ユーザーを連携アプリのリソースにアクセスさせるため、リダイレクトします。
（13）ブラウザは、RPに連携アプリのリソースを要求します。
（14）RPは、ユーザーが認証済であるため、保護されていた連携アプリのリソースを要求します。
（15）連携アプリは、RPへ連携アプリのリソースを返却します。
（16）RPは、ユーザーへ連携アプリのリソースを返却します。

※OpenID Connectのプロトコル標準仕様（RFC）上では、ID情報の受入側を「RP（Relying Party）」、ID情報の提供側を「OP（OpenID Provider）」と表現されます。