15.5. Microsoft Entra ID で Red Hat build of HawtIO と OpenID Connect 認証を使用する
Red Hat build of HawtIO 4 は、Microsoft Entra ID でもテストされています。理論上、関連する OpenID プロバイダーメタデータ にアクセスできれば OpenID Connect プロバイダーを使用できるはずですが、実際はプロバイダー固有の設定が必要です。
クライアント は、"App registrations" ブレードを使用して Entra ID に登録されます。アプリケーションの登録時に最も重要となるのは、リダイレクト URI のプラットフォームの種類を決定することです。
選択できるオプションは 2 つあります ("パブリッククライアント/ネイティブ (モバイルとデスクトップ)" プラットフォームは考慮しません)。この UI は、後でリダイレクト URI を設定するときに表示されます。
一見するだけでは何を選択するべきかわからないかもしれませんが、次のように記述すれば十分です。
Web プラットフォーム:
この種類のクライアントは、サーバー側のアプリケーションや API に適しています。
SPA プラットフォーム:
SPA アプリケーションはブラウザー内で実行されるため、"認可コードフロー" と、いわゆるパブリッククライアントを使用するのが自然です。なぜなら、ブラウザーアプリケーションに認証情報と秘密を保存する適切な方法がないからです。
SPA プラットフォームを選択すると、Entra ID UI に次のマークが表示されます。
15.5.1. Entra ID で単一の SPA クライアントを使用する リンクのコピーリンクがクリップボードにコピーされました!
Entra ID で SPA クライアントを設定した後、hawtio-oidc.properties で関連するオプションを設定できます。Entra ID の "App registrations" ブレードで "Endpoints" タブをクリックすると、次の内容が表示されます。
テナント ID は、使用されている Entra ID/Azure テナントに固有の UUID です。以下は Red Hat build of HawtIO の設定です。この場合の provider はテナントのベース URL、client_id は Overview of App Registration ページの "Application (client) ID" です。
# OpenID Connect configuration requred at client side
# URL of OpenID Connect Provider - the URL after which ".well-known/openid-configuration" can be appended for
# discovery purposes
provider = https://login.microsoftonline.com/00000000-1111-2222-3333-444444444444/v2.0
# OpenID client identifier
client_id = 55555555-6666-7777-8888-999999999999
# response mode according to https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
response_mode = fragment
# scope to request when performing OpenID authentication. MUST include "openid" and required permissions
scope = openid email profile
# redirect URI after OpenID authentication - must also be configured at provider side
redirect_uri = http://localhost:8080/hawtio
# challenge method according to https://datatracker.ietf.org/doc/html/rfc7636
code_challenge_method = S256
# prompt hint according to https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
prompt = login
このような設定 (openid email profile が scope パラメーターとして送信される) の問題点は、実際には email openid profile User がスコープとして想定されることです。読み取りおよび付与されたアクセストークンは次のとおりです (関連する JWT クレームのみ表示)。
{
"aud": "00000003-0000-0000-c000-000000000000",
"iss": "https://sts.windows.net/8fd8ed3d-c739-410f-83ab-ac2228fa6bbf/",
...
"app_displayname": "hawtio",
...
"scp": "email openid profile User.Read",
...
}
aud (オーディエンス) クレームは 00000003-0000-0000-c000-000000000000 であり、これは … Microsoft Graph API の OAuth2 クライアント ID です。
このようなアクセストークンは、Red Hat build of HawtIO サーバー (Jolokia エージェントを使用) で使用されません。さらに、署名も Microsoft Graph API に関連付けられたキーを使用して作成されます。
Entra ID を適切に設定し、生成されたアクセストークンが Red Hat build of HawtIO Server で 使用できる ことを確実化するためには、Red Hat build of HawtIO Client と Server のそれぞれに対して (つまり合計 2 つの) アプリケーション登録 が必要です。次のサブチャプターを参照してください。
15.5.2. Entra ID で Web クライアントと SPA を使用する リンクのコピーリンクがクリップボードにコピーされました!
Entra ID で 2 つのアプリケーション登録を設定することが推奨されます。
- Red Hat build of HawtIO クライアントアプリケーション用の SPA クライアント - PKCE が有効になっている OAuth2 パブリッククライアント を設定する方法です。
-
Red Hat build of HawtIO Server アプリケーションの Web (API) (実際は Jolokia API) - たとえば
api://hawtio-server/Jolokia.Accessという名前のスコープとして表される API を公開する Entra ID。これは上記の Red Hat build of HawtIO Client アプリケーションで許可済み API として設定されます。
最後に、認可コードフロー が開始されると、スコープパラメーターで要求されたスコープの 1 つが、Red Hat build of HawtIO サーバーアプリケーションに定義された scope になります (api://hawtio-server/Jolokia.Access など)。
Entra ID で必要な設定をまとめてみましょう。
-
"Web" リダイレクト URI を使用して
hawtio-serverアプリケーション登録を作成します。 "Expose an API" セクションで、Red Hat build of HawtIO クライアントから要求される可能性のあるアクセススコープを表すスコープを追加します。
これにより、後で使用する参照可能な
api://hawtio-server/Jolokia.Accessスコープが作成されます。hawtio-serverの "App roles" セクションで、このクライアントのスコープ内のユーザーに割り当てるロールを定義します。以下はその例です。
hawtio-serverの "Enterprise Applications" ブレードで、"Users and groups" タブに移動し、ユーザーロールの割り当てを追加します。以下に例を示します。
"SPA" リダイレクト URI を使用して
hawtio-clientアプリケーション登録を作成します。
hawtio-clientアプリケーション登録の "API Permissions" セクションで、hawtio-server公開 API の 委譲権限 を追加します。
これにより、次のような委譲済み権限セットが設定されます。
注記委譲済み権限の詳細は、Microsoft Entra ID ドキュメント を参照してください。
-
Enterprise Application ブレードの
hawtio-clientに、ユーザーとロールのマッピングは必要ありません。 上記の設定を行うと、Red Hat build of HawtIO 設定で
scopeパラメーターを適切に設定できます。これにより、後で使用する参照可能な
api://hawtio-server/Jolokia.Accessスコープが作成されます。-
hawtio-serverの "App roles" セクションで、このクライアントのスコープ内のユーザーに割り当てるロールを定義します。以下はその例です。 -
hawtio-serverの "Enterprise Applications" ブレードで、"Users and groups" タブに移動し、ユーザーロールの割り当てを追加します。以下に例を示します。 -
"SPA" リダイレクト URI を使用して
hawtio-clientアプリケーション登録を作成します。 hawtio-clientアプリケーション登録の "API Permissions" セクションで、hawtio-server公開 API の委譲済み権限を追加します。これにより、次のような委譲済み権限セットが設定されます。
注記委譲済み権限の詳細は、Microsoft Entra ID ドキュメント を参照してください。
-
Enterprise Application ブレードの
hawtio-clientに、ユーザーとロールのマッピングは必要ありません。
上記の設定を行うと、Red Hat build of HawtIO 設定でスコープパラメーターを適切に設定できます。
# scope to request when performing OpenID authentication. MUST include "openid" and required permissions
scope = openid email profile api://hawtio-server/Jolokia.Access
15.5.3. アクセストークンの設定 リンクのコピーリンクがクリップボードにコピーされました!
最後になりますが、非常に重要な設定項目がトークン設定です。Red Hat build of HawtIO Server を表すアプリケーション (および付与されたアクセストークンを使用するコンポーネント) である hawtio-server アプリケーションの登録では、groups クレームがアクセストークンに追加されていることを確認する必要があります。
最小限の設定は次のとおりです。
groups クレームには セキュリティーグループ と ディレクトリーロール を含める必要があり、グループは UUID ではなく名前で表す必要があります。
参考までに、hawtio-server アプリケーション登録のマニフェストに関連する JSON スニペットを次に示します。
"optionalClaims":
{
"idToken":
[
{
"name": "groups",
"source": null,
"essential": false,
"additionalProperties": []
}
],
"accessToken":
[
{
"name": "groups",
"source": null,
"essential": false,
"additionalProperties":
[
"sam_account_name"
]
},
...
付与されたアクセストークンは、Microsoft Graph API オーディエンス固有のものではなくなります。これは hawtio-server 用になります。aud クレームは hawtio-server アプリケーション登録の UUID、appid クレームは hawtio-client アプリケーション登録の UUID です。
{
"aud": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
"iss": "https://sts.windows.net/.../",
"iat": 1709626257,
"nbf": 1709626257,
"exp": 1709630939,
...
"appid": "55555555-6666-7777-8888-999999999999",
...
"groups":
[
...
],
...
"name": "hawtio-viewer",
...
"roles":
[
"Red Hat buuld of HawtIO.User"
],
"scp": "Jolokia.Access",
このロールは変換され (マッピングを含む場合もある) は、roles クレームで使用可能になり、設定に反映されます。
# a path for an array of roles found in JWT payload. Property placeholders can be used for parameterized parts
# of the path (like for Keycloak) - but only for properties from this particular file
# example for properly configured Entra ID token
#oidc.rolesPath = roles
...
# properties for role mapping. Each property with "roleMapping." prefix is used to map an original role
# from JWT token (found at ${oidc.rolesPath}) to a role used by the application
roleMapping.Red Hat buuld of HawtIO.User = user
...