第16章 OpenID Connect インテグレーション
HawtIO は、すでに OpenID プロバイダー として Keycloak をサポートしています。ただし、Keycloak は、HawtIO で使用される設定方法が非推奨であることを すでに発表しています。OpenID Connect Core 1.0 は、分散認証 (OAuth 2 に基づく) の広く普及した仕様および標準方式であるため、HawtIO 4 では汎用 OpenID 認証がサポートされるようになりました。
16.1. ビルディングブロックと用語 リンクのコピーリンクがクリップボードにコピーされました!
ここでは、HawtIO が OpenID Connect と OAuth2 をどのように使用するかを理解するために、いくつかの基本的な概念を最確認します。OpenID Connect に基づく分散認証 (OAuth2 上に構築) には、主に 3 つの要素が関与しています。
リソースサーバー:
保護されたリソースをホストするサーバーコンポーネント。アクセスはアクセストークンに基づき制限または許可されます。通常、このサーバーは REST API を介してアクセスされ、サーバーがユーザーインターフェイスを提供することはありません。
クライアント:
ユーザー (リソース所有者として扱われる) に代わってリソースサーバーにアクセスするアプリケーション (通常はユーザーインターフェイスを持っています)。リソースサーバーにアクセスするには、まずクライアントがアクセストークンを取得する必要があります。
OpenID Connect 仕様では、クライアントはリライングパーティー (RP) と呼ばれます。
認可サーバー:
クライアントとリソースサーバー間の通信を調整するサーバー。クライアントは認可サーバーにユーザー (リソース所有者) を認証するように要求し、認証が成功すると、リソースサーバーにアクセスするためのアクセストークンがクライアントに発行されます。
OpenID Connect 仕様では、認可サーバーは OpenID プロバイダー (OP) と呼ばれます。
OAuth2 と OpenID Connect の主な目的は、アプリケーションがユーザー認証情報を使用せずに API にアクセスし、トークンエクスチェンジに切り替えることを可能にすることです。HawtIO が上記の役割にどのようにマッピングされるかを知ることが重要です。
- HawtIO クライアントアプリケーションは OAuth2 クライアントです。ユーザーは HawtIO Web アプリケーションと対話し、Hawtio Web アプリケーションは Jolokia エージェントが実行されている HawtIo サーバー (バックエンド) と通信します。Jolokia エージェントにアクセスする前に、HawtIO には OpenID Connect アクセストークンが必要です。そのため、HawtIO クライアントは、ユーザーを認可サーバーにリダイレクトして OpenID Connect 認証プロセスを開始します。
- HawtIO サーバーアプリケーションは、Jolokia エージェント API を公開する JakartaEE アプリケーションです。Jolokia エージェント API は、アクセストークンの内容に基づきユーザーアクションを承認します。OAuth2 用語では、HawtIO サーバーはリソースサーバーです。
以下の UML 図は全体像を示しています。
最も重要なのは、HawtIO クライアントがユーザーの認証情報を処理することはないという点です。ユーザーは認可サーバーで認証し、HawtIO クライアントは後で HawtIO サーバー (およびその Jolokia API) へのアクセスに使用するアクセストークンのみ取得します。