Menu Close
Settings Close

Language and Page Formatting Options

第12章 OpenID Connect および SAML クライアントの管理

クライアントは、ユーザーの認証を要求できるエンティティーです。クライアントは 2 つの形式で提供されます。クライアントの最初のタイプは、single-sign-on に参加するアプリケーションです。これらのクライアントは、Red Hat Single Sign-On によるセキュリティーの提供のみを行います。他のタイプのクライアントは、認証されたユーザーの代わりに他のサービスを呼び出すことができるように、アクセストークンを要求するものです。このセクションでは、クライアントの設定に関するさまざまな側面と、その方法について説明します。

12.1. OIDC クライアント

OpenID Connect は、アプリケーションのセキュリティーを保護するのに推奨されるプロトコルです。Web でも簡単に使用できるように、ゼロから設計されているので、HTML5/JavaScript アプリケーションで最適に動作します。

12.1.1. OpenID Connect クライアントの作成

OpenID 接続プロトコルを使用するアプリケーションを保護するには、クライアントを作成します。

手順

  1. メニューで Clients をクリックします。
  2. Create をクリックして Add Client ページに移動します。

    クライアントの追加

    Add Client

  3. Client ID の名前を入力します。
  4. Client Protocol ドロップダウンメニューで openid-connect を選択します。
  5. Root URL フィールドにアプリケーションのベース URL を入力します。
  6. Save をクリックします。

このアクションにより、クライアントが作成され、Settings タブが表示されます。

クライアントの設定

Client Settings

関連情報

  • OIDC プロトコルの詳細については、OpenIDConnect を参照してください。

12.1.2. 基本設定

OIDC クライアントを作成すると、Settings タブに以下のフィールドが表示されます。

Client ID
OIDC 要求で使用される英数字 ID 文字列および Red Hat Single Sign-On データベースでクライアントを特定します。
名前
Red Hat Single Sign-On UI 画面のクライアントの名前。名前をローカライズするには、代替文字列値を設定します。たとえば、${myapp} などの文字列値です。詳細は、サーバー開発者ガイドを参照してください。
Description
クラスターの説明。この設定はローカライズすることもできます。
Enabled
オフにすると、クライアントは認証を要求できません。
Consent Required
これを有効にすると、アプリケーションへのアクセス権限付与に使用できる同意ページが表示されます。またメタデータも表示し、クライアントがアクセスできる正確な情報をユーザーが認識できるようにします。
アクセスタイプ
OIDC クライアントのタイプ。
Confidential
ブラウザーログインを実行し、アクセストークン要求の実行時にクライアントシークレットを必要とするサーバー側のクライアントの場合。この設定はサーバー側のアプリケーションに使用する必要があります。
公開
ブラウザーログインを実行するクライアント側のクライアントの場合。クライアント側のクライアントでシークレットを安全に保つことができないため、正しいリダイレクト URI を設定してアクセスを制限することが重要です。
Bearer-only
アプリケーションは Bearer トークン要求のみを許可します。これがオンの場合、このアプリケーションはブラウザーログインに参加できません。
Standard Flow Enabled
有効にすると、クライアントは OIDC Authorization Code Flow を使用できます。
Implicit Flow Enabled
有効にすると、クライアントは OIDC Implicit Flow を使用できます。
Direct Access Grants Enabled
有効にすると、クライアントは OIDC Direct Access Grants を使用できます。
OAuth 2.0 デバイス認証付与の有効化
On の場合、クライアントは OIDC Device Authorization Grant を使用できます。
OpenID Connect クライアントが開始したバックチャネル認証の付与
On の場合、クライアントは OIDC Client Initiated Backchannel Authentication Grant を使用できます。
Root URL
Red Hat Single Sign-On で設定された相対 URL が使用される場合、この値はそれらの先頭に追加されます。
Valid Redirect URIs

必須フィールド。URL パターンを入力し、+ をクリックして既存の URL を追加し、-Save の順にクリックします。URL パターンの最後にワイルドカードを使用できます。例: http://host.com/*

通常、排他的リダイレクト URL パターンの方が安全です。詳細は unspecific Redirect URIs を参照してください。

Base URL
Red Hat Single Sign-On がクライアントへのリンクが必要な場合は、この URL が使用されます。
Admin URL
クライアントのコールバックエンドポイント。サーバーは、この URL を使用して失効ポリシーのプッシュ、バックチャネルログアウトの実行などのコールバックを行います。Red Hat Single Sign-On サーブレットアダプターでは、サーブレットアプリケーションのルート URL を使用できます。詳細は、アプリケーションおよびサービスガイドを参照してください。

ロゴ URL

クライアントアプリケーションのロゴを参照する URL。

ポリシー URL

プロファイルデータがどのように使用されるかについて読むために、証明書利用者クライアントがエンドユーザーに提供する URL。

サービス URL の用語

依拠当事者の利用規約について読むために、依拠当事者クライアントがエンドユーザーに提供する URL。

Web Origins

URL パターンを入力し、+ をクリックして既存の URL を追加し、- をクリックして削除します。Save をクリックします。

このオプションは、CORS(Cross-Origin Resource Sharing) を処理します。ブラウザーの JavaScript が、JavaScript コードの元のドメインとは異なるドメインを持つサーバーに対して AJAX HTTP リクエストを試行する場合、リクエストは CORS を使用する必要があります。サーバーは、CORS リクエストを処理する必要があります。処理しないと、ブラウザーは表示されず、リクエストの処理を許可しません。このプロトコルは、XSS、CSRF、およびその他の JavaScript ベースの攻撃から保護します。

ここに記載のドメイン URL は、クライアントアプリケーションに送信されたアクセストークン内に埋め込まれています。クライアントアプリケーションはこの情報を使用して、CORS リクエストの呼び出しを許可するかどうかを決定します。この機能をサポートするのは、Red Hat Single Sign-On クライアントアダプターのみです。詳細は、アプリケーションおよびサービスガイドを参照してください。

フロントチャンネルのログアウト
フロントチャネルログアウト が有効になっている場合、アプリケーションは、OpenID Connect フロントチャネルログアウト 仕様に従って、フロントチャネルを介してユーザーをログアウトできる必要があります。有効になっている場合は、フロントチャネルログアウト URL も指定する必要があります。
フロントチャネルログアウト URL
フロントチャネルを介してクライアントにログアウト要求を送信するために Red Hat Single Sign-On によって使用される URL。
バックチャネルログアウト URL
ログアウト要求がこのレルムに (end_session_endpoint 経由で) 送信されたときにクライアントが自分自身をログアウトさせる URL。省略した場合、ログアウト要求はクライアントに送信されません。

12.1.3. 詳細設定

Advanced Settings をクリックすると、追加のフィールドが表示されます。

OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled

注記

Red Hat Single Sign-On で相互 TLS を有効にするには、「WildFly で相互 SSL の有効化」を参照してください。

相互 TLS は、アクセストークンと更新トークンをクライアント証明書と共にバインドします。クライアント証明書は、TLS ハンドシェイク時に交換されます。このバインディングは、攻撃者が盗まれたトークンを使用するのを防ぎます。

このタイプのトークンは holder-of-key トークンです。Bearer トークンとは異なり、holder-of-key トークンの受信側は、トークンの送信側が正当であるかどうかを検証できます。

この設定が有効な場合に、ワークフローは以下のようになります。

  1. トークンリクエストが、認可コードフローまたはハイブリッドフローのトークンエンドポイントに送信される。
  2. Red Hat Single Sign-On はクライアント証明書を要求する。
  3. Red Hat Single Sign-On はクライアント証明書を受け取る。
  4. Red Hat Single Sign-On はクライアント証明書を正常に検証する。

検証に失敗すると、Red Hat Single Sign-On はトークンを拒否します。

以下の場合、Red Hat Single Sign-On は、アクセストークンまたは更新トークンを送信するクライアントを確認します。

  • トークンの更新リクエストは、holder-of-key 更新トークンでトークンエンドポイントに送信されます。
  • UserInfo リクエストは、holder-of-key アクセストークンで UserInfo エンドポイントに送信されます。
  • ログアウトリクエストは、holder-of-key 更新トークンで Logout エンドポイントに送信されます。

詳細は、OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens のMutual TLS Client Certificate Bound Access Tokensを参照してください。

注記

現在、Red Hat Single Sign-On クライアントアダプターは holder-of-key トークン検証をサポートしていません。Red Hat Single Sign-On アダプターは、アクセスおよび更新トークンを Bearer トークンとして扱います。

Proof Key for Code Exchange Code Challenge Method

攻撃者が正当なクライアントの認証コードを盗んだ場合には、PKCE (Proof Key for Code Exchange) により、コードに適用されるトークンを、攻撃者が受け取れないようにします。

管理者は、以下のオプションのいずれかを選択できます。

(blank)
クライアントが適切な PKCE パラメーターを Red Hat Single Sign-Ons 承認エンドポイントに送信する限り、Red Hat Single Sign-On は PKCE を適用しません。
S256
Red Hat Single Sign-On は、コードのチャレンジメソッドが S256 であるクライアント PKCE に適用されます。
plain
Red Hat Single Sign-On は、コードのチャレンジメソッドが plain のクライアント PKCE に適用されます。

詳細は、OAuth パブリッククライアントによるコード Exchange の RFC 7636 Proof キー を参照してください。

Signed and Encrypted ID Token Support

Red Hat Single Sign-On は、Json Web Encryption (JWE) 仕様に従って ID トークンを暗号化できます。管理者は、各クライアントに対して ID トークンが暗号化されているかどうかを判断します。

ID トークンの暗号化に使用されるキーは、コンテンツ暗号化キー(CEK)です。Red Hat Single Sign-On およびクライアントは、使用する CEK と配信する方法をネゴシエートする必要があります。CEK の決定に使用されるメソッドは鍵管理モードです。Red Hat Single Sign-On がサポートする鍵管理モードは、鍵の暗号化です。

キーの暗号化の場合:

  1. クライアントは非対称暗号キーペアを生成します。
  2. 公開鍵は CEK の暗号化に使用されます。
  3. Red Hat Single Sign-On は、ID トークンごとに CEK を生成します。
  4. Red Hat Single Sign-On は、この生成された CEK を使用して ID トークンを暗号化します。
  5. Red Hat Single Sign-On は、クライアントの公開鍵を使用して CEK を暗号化します。
  6. クライアントは、秘密鍵を使用して暗号化された CEK を復号します。
  7. クライアントは復号化された CEK を使用して ID トークンを復号化します。

クライアント以外のパーティーは ID トークンを復号化できます。

クライアントは、CEK を暗号化する公開鍵を Red Hat Single Sign-On に渡す必要があります。Red Hat Single Sign-On は、クライアントが提供する URL からの公開鍵のダウンロードをサポートします。クライアントは、Json Web Keys(JWK) 仕様に従って公開鍵を提供する必要があります。

手順は以下のとおりです。

  1. クライアントの Keys タブを開きます。
  2. JWKS URL を ON に切り替えます。
  3. JWKS URL テキストボックスにクライアントの公開鍵 URL を入力します。

キー暗号化のアルゴリズムは、Json Web Algorithm (JWA) 仕様で定義されています。Red Hat Single Sign-On は以下をサポートします。

  • RSAES-PKCS1-v1_5(RSA1_5)
  • デフォルトパラメーターを使用した RSAES OAEP(RSA-OAEP)
  • SHA-256 と MFG1(RSA-OAEP-256)を使用した RSAES OAEP 256

アルゴリズムを選択する手順は次のとおりです。

  1. クライアントの Settings タブを開きます。
  2. Fine Grain OpenID Connect Configuration を開きます。
  3. ID Token Encryption Content Encryption Algorithm プルダウンメニューからアルゴリズムを選択します。

ACR から認証レベル (LoA) へのマッピング

クライアントの詳細設定では、どの Authentication Context Class Reference (ACR) 値をどの Level of Authentication (LoA) マップするかを定義できます。このマッピングは、ACR から LoA へのマッピング で説明されているようにレルムでも指定できます。ベストプラクティスは、このマッピングをレルムレベルで設定することです。これにより、複数のクライアント間で同じ設定を共有できます。

Default ACR Values を使用して、ログイン要求がこのクライアントから Red Hat Single Sign-On に acr_values パラメーターなしで、acr クレームが付加された claims パラメーターなしで送信される場合のデフォルト値を指定できます。公式の OIDC 動的クライアント登録仕様 を参照してください。

警告

デフォルトの ACR 値がデフォルトのレベルとして使用されますが、特定のレベルでのログインを強制するために確実に使用できるわけではないことに注意してください。たとえば、Default ACR Values をレベル 2 に設定するとします。次に、デフォルトで、ユーザーはレベル 2 で認証する必要があります。ただし、ユーザーが acr_values=1 などのログイン要求にパラメーターを明示的にアタッチすると、レベル 1 が使用されます。その結果、クライアントが本当にレベル 2 を必要とする場合、クライアントは ID トークン内の acr クレームの存在を確認し、要求されたレベル 2 が含まれていることを再確認することをお勧めします。

ACR to LoA mapping

詳細は、ステップアップ認証公式の OIDC 仕様を参照してください。

12.1.4. 機密なクライアント認証情報

クライアントの アクセスタイプconfidential に設定されている場合には、クライアントの認証情報は Credentials タブで設定する必要があります。

認証情報タブ

Credentials Tab

Client Authenticator ドロップダウンリストは、クライアントに使用する認証情報のタイプを指定します。

クライアント ID およびシークレット

この選択はデフォルトの設定です。シークレットは自動的に生成され、必要に応じて Regenerate Secret がシークレットを再作成します。

署名付き JWT

client credentials jwt

署名済み JWT は「Signed Json Web Token」です。

この認証情報タイプを選択すると、Keys タブでクライアントの秘密鍵と証明書も生成する必要があります。秘密鍵は JWT に署名するために使用されます。一方、証明書は、署名の検証にサーバーによって使用されます。

keys タブ

client oidc keys

Generate new keys and certificate ボタンをクリックして、このプロセスを開始します。

キーの生成

generate client keys

  1. 使用するアーカイブ形式を選択します。
  2. 鍵パスワード を入力します。
  3. ストアパスワード を入力します。
  4. Generate and Download をクリックします。

これらのキーを生成すると、Red Hat Single Sign-On は証明書を保存し、クライアントが使用する秘密鍵と証明書をダウンロードする必要があります。

外部ツールを使用して鍵を生成し、Import Certificate をクリックしてクライアントの証明書をインポートすることもできます。

証明書のインポート

Import Certificate

  1. 証明書のアーカイブ形式を選択します。
  2. ストアパスワードを入力します。
  3. Import File をクリックして証明書ファイルを選択します。
  4. Import をクリックします。

JWKS URL を使用 をクリックすると、証明書をインポートする必要がなくなります。この場合、公開鍵が JWK 形式で公開される URL を指定できます。このオプションを使用すると、鍵が変更された場合、Red Hat Single Sign-On はキーを再インポートします。

Red Hat Single Sign-On アダプターで保護されたクライアントを使用している場合は、https://myhost.com/myapp がクライアントアプリケーションのルート URL であると仮定して、この形式で JWKS URL を設定できます。

https://myhost.com/myapp/k_jwks

詳細は サーバー開発者ガイド を参照してください。

警告

Red Hat Single Sign-On は、OIDC クライアントの公開鍵をキャッシュします。クライアントの秘密鍵が危険にさらされた場合は、キーを更新して、鍵キャッシュをクリアします。詳細は、「キャッシュのクリア」セクションを参照してください。

クライアントシークレットでの署名済み JWT

このオプションを選択する場合は、秘密鍵の代わりにクライアントシークレットで署名された JWT を使用できます。

このクライアントシークレットは、クライアントによって JWT に署名するために使用されます。

X509 証明書

クライアントが TLS Handshake 時に適切な X509 証明書を使用する場合に Red Hat Single Sign-On を検証します。

注記

このオプションには、Red Hat Single Sign-On に相互 TLS が必要です。「WildFly での相互 SSL の有効化」を 参照してください。

X509 証明書

x509 client auth

バリデーターは、設定された正規表現検証式を使用して、証明書のサブジェクト DN フィールドも確認します。いくつかのユースケースでは、すべての証明書を受け入れるだけで十分です。この場合は、(.*?)(?:$) 式を使用できます。

Red Hat Single Sign-On がリクエストからクライアント ID を取得する方法は 2 つあります。

  • クエリー内の client_id パラメーター (OAuth 2.0 仕様 のセクション 2.2 で説明されています)。
  • client_id をフォームパラメーターとして指定します。

12.1.5. クライアントのシークレットローテーション

注記

クライアントシークレットローテーションは テクノロジープレビュー であり、完全にはサポートされていません。この機能はデフォルトで無効にされています。

-Dkeycloak.profile=preview または -Dkeycloak.profile.feature.web_authn=enabled でサーバーの起動を有効にするには、以下を行います、詳細は、Profiles を参照してください。

ConfidentialAccess Type のクライアントの場合、Red Hat Single Sign-On は、クClient Policies を介してクライアントシークレットをローテーションする機能をサポートします。

クライアントシークレットローテーションポリシーは、シークレットの漏えいなどの問題を軽減するため、セキュリティーが強化されます。有効にすると、Red Hat Single Sign-On はクライアントごとに最大 2 つのアクティブなシークレットをサポートします。ポリシーは、以下の設定に従ってローテーションを管理します。

  • シークレットの有効期限: [秒]:- シークレットがローテーションされると、これは新しいシークレットの有効期限です。シークレット作成日に追加された量 (秒単位)。ポリシー実行時に計算されます。
  • ローテーションされたシークレットの有効期限: [秒]: シークレットがローテーションされた場合、この値は古いシークレットの残りの有効期限です。この値は、常にシークレットの有効期限よりも小さくする必要があります。値が 0 の場合、クライアントのローテーション時に古いシークレットはすぐに削除されます。シークレットローテーションの日付に追加された量 (秒単位)。ポリシー実行時に計算されます。
  • 更新中のローテーションの残りの有効期限: [秒]: 動的クライアントへの更新でクライアントシークレットローテーションを実行する必要がある期間。ポリシー実行時に計算されます。

クライアントシークレットのローテーションが発生すると、新規のメインシークレットが生成され、古いクライアントシークレットが新しい有効期限を持つセカンダリーシークレットになります。

12.1.5.1. クライアントシークレットローテーションのルール

ローテーションは自動的に行われないか、バックグラウンドプロセスを介して行われません。ローテーションを実行するには、クライアントの credentials タブまたは Admin REST API の Regenerate Secret による Red Hat Single Sign-On 管理コンソールを介して、クライアントに更新アクションが必要です。クライアント更新アクションを呼び出すと、シークレットのローテーションはルールに基づいて行われます。

  • シークレットの有効期限の値が現在の日付未満の場合。
  • 動的クライアント登録クライアント更新要求中に、更新中のローテーションの残りの有効期限 の値が現在の日付と シークレットの有効期限 の間の期間と一致する場合、クライアントシークレットは自動的にローテーションされます。

さらに、Admin REST API を介して、いつでもクライアントシークレットローテーションを強制することができます。

注記

新規クライアントの作成時に、クライアントシークレットのローテーションポリシーがアクティブになると、動作が自動的に適用されます。

警告

シークレットローテーション動作を既存のクライアントに適用するには、ポリシーを定義した後でそのクライアントを更新して、動作が適用されるようにします。

12.1.6. OIDC クライアントシークレットローテーションポリシーの作成

以下は、シークレットローテーションポリシーを定義する例です。

手順

  1. 左側のメニューで Realm Settings をクリックします。
  2. Client Policies タブをクリックします。
  3. Profiles ページで Createをクリックします。

    プロファイルの作成

    Create Client Profile

  4. Name に任意の名前を入力します。
  5. Description のプロファイルの目的を特定するのに役立つ説明を入力します。
  6. Save をクリックします。

    このアクションによりプロファイルが作成され、エグゼキューターを設定できます。

  7. Create をクリックして、このプロファイルにエグゼキューターを設定します。

    プロファイルエグゼキューターの作成

    Client Profile Executor

  8. Executor Typesecret-rotation を選択します。
  9. Secret Expiration の各シークレットの最大継続時間を秒単位で入力します。
  10. Rotated Secret Expiration について、ローテーションされた各シークレットの最大継続時間を秒単位で入力します。

    警告

    Rotated Secret Expiration の値は、常に Secret Expiration りも小さくする必要があることに注意してください。

  11. 更新アクションがクライアントの RemainExpirationTime を更新するまでの時間を秒単位で入力します。
  12. Save をクリックします。

    注記

    上記の例では、以下のようになります。

    • 各シークレットは 1 週間で有効です。
    • ローテーションされたシークレットは 2 日後に有効期限が切れます。
    • 動的クライアントを更新するウィンドウは、シークレットの有効期限が切れる前に 1 日後に開始します。
  13. Client Policies タブに戻ります。
  14. Policies をクリックします。
  15. Create をクリックします。

    クライアントシークレットローテーションポリシーの作成

    Client Rotation Policy

  16. Name に任意の名前を入力します。
  17. Description のポリシーの目的を特定するのに役立つ説明を入力します。
  18. Save をクリックします。

    このアクションによりポリシーが作成され、ポリシーをプロファイルに関連付けることができます。また、ポリシー実行の条件を設定することもできます。

  19. Condition で、Create をクリックします。

    クライアントシークレットローテーションポリシー条件の作成

    Client Rotation Policy Condition

  20. すべての機密クライアントに動作を適用するには、Condition Type フィールドで client-access-type を選択します。

    注記

    クライアントの特定のグループに適用するには、Condition Type フィールドに client-roles タイプを選択する方法もあります。これにより、特定のロールを作成し、カスタムのローテーション設定を各ロールに割り当てることができます。

  21. Client Access Type フィールドに confidential を追加します。
  22. Save をクリックします。
  23. ポリシー設定に戻り、Client Profiles の下にある Add client profile 選択メニューで、以前に作成したプロファイル Weekly Client Secret Rotation Profile を選択します。

クライアントシークレットローテーションポリシー

Client Rotation Policy

注記

シークレットのローテーション動作を既存のクライアントに適用するには、以下の手順に従います。

管理コンソールの使用

  1. 一部のクライアントに移動します。
  2. Credentials タブに移動します。
  3. Re-generate secret クリックします。

クライアント REST サービスを使用すると、以下のいずれかの方法で実行できます。

  • クライアントでの更新操作経由
  • 再生成クライアントシークレットエンドポイント経由

12.1.7. サービスアカウントの使用

各 OIDC クライアントには、ビルトインの サービスアカウント があります。この サービスアカウント を使用してアクセストークンを取得します。

手順

  1. メニューで Clients をクリックします。
  2. クライアントを選択します。
  3. Settings タブをクリックします。
  4. クライアントの Access Typeconfidential に設定します。
  5. Service Accounts EnabledON に切り替えます。
  6. Save をクリックします。
  7. クライアントのクレデンシャル を設定します。
  8. Scope タブをクリックします。
  9. ロールがあることを確認するか、Full Scope AllowedON に切り替えます。
  10. Service Account Roles タブをクリックします。
  11. クライアントのこのサービスアカウントで利用可能なロールを設定します。

アクセストークンからのロールは、以下の交差部分になります。

  • クライアントのロールスコープと、リンクされたクライアントスコープから継承されたロールスコープのマッピング
  • サービスアカウントロール

呼び出す REST URL は /auth/realms/{realm-name}/protocol/openid-connect/token です。この URL は POST 要求として呼び出され、要求でクライアントクレデンシャルを投稿する必要があります。

デフォルトでは、クライアント認証情報は Authorization: Basic ヘッダーでクライアントの clientId および clientSecret によって表されますが、署名付きの JWT アサーションやその他のクライアント認証用のカスタムメカニズムを使ってクライアントを認証することもできます。

OAuth2 仕様に従って、grant_type パラメーターを client_credentials に設定する必要があります。

たとえば、サービスアカウントを取得する POST 呼び出しは以下のようになります。

    POST /auth/realms/demo/protocol/openid-connect/token
    Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
    Content-Type: application/x-www-form-urlencoded

    grant_type=client_credentials

応答は、OAuth 2.0 仕様からのこの アクセストークン応答 と似ています。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60
}

デフォルトでは、アクセストークンのみが返されます。更新トークンが返されず、認証の成功時に Red Hat Single Sign-On 側でユーザーセッションは作成されません。更新トークンがないため、アクセストークンの期限が切れると再認証が必要になります。ただし、この状況は、セッションがデフォルトで作成されていないため、Red Hat Single Sign-On サーバーでオーバーヘッドが追加されるわけではありません。

このような状況では、ログアウトは必要ありません。ただし、発行されたアクセストークンは、OpenID Connect Endpoints セクションで説明するように、OAuth2 Revocation Endpoint にリクエストを送信して取り消すことができます。

関連情報

詳細は、クライアント認証情報の付与 を参照してください。

12.1.8. オーディエンスのサポート

通常、Red Hat Single Sign-On のデプロイ環境は、認証に Red Hat Single Sign-On を使用する 機密 または 公開 クライアントアプリケーションのセットで構成されます。

また、クライアントアプリケーションからの要求に対応し、これらのアプリケーションにリソースを提供する サービス (OAuth 2 仕様リソースサーバー)も利用できます。これらのサービスでは、要求の認証に アクセストークン (Bearer トークン)を送信する必要があります。このトークンは、Red Hat Single Sign-On へのログイン時にフロントエンドアプリケーションで取得されます。

サービス間の信頼性が低い環境では、以下のシナリオが発生する可能性があります。

  1. フロントエンドクライアントアプリケーションには、Red Hat Single Sign-On に対する認証が必要である。
  2. Red Hat Single Sign-On はユーザーを認証する。
  3. Red Hat Single Sign-On はトークンをアプリケーションに発行する。
  4. アプリケーションはトークンを使用して信頼できないサービスを呼び出す。
  5. 信頼できないサービスはアプリケーションへの応答を返す。ただし、アプリケーショントークンを保持します。
  6. その後、信頼されていないサービスは、アプリケーショントークンを使用して信頼されるサービスを呼び出す。これにより、信頼できないサービスがトークンを使用してクライアントアプリケーションの代わりに他のサービスにアクセスするため、セキュリティーが損なわれます。

このシナリオは、サービス間の信頼度が高い環境では発生する可能性が低いですが、信頼度が低い環境では発生する可能性があります。一部の環境では、信頼されていないサービスが信頼できるサービスからデータを取得して、元のクライアントアプリケーションにデータを返す必要があるため、このワークフローは正しい場合があります。

対象範囲に制限がないと、サービス間で高いレベルの信頼が存在する場合に役立ちます。そうでない場合は、対象範囲を制限する必要があります。対象範囲を制限しつつ、信頼できないサービスが信頼できるサービスからデータを取得できるようにしますこの場合は、信頼できないサービスと信頼できるサービスが対象としてトークンに追加されていることを確認します。

アクセストークンの誤用を防ぐには、トークンの対象範囲を制限し、トークンの対象を確認するようにサービスを設定します。フローは以下のように変わります。

  1. フロントエンドアプリケーションは、Red Hat Single Sign-On に対して認証されます。
  2. Red Hat Single Sign-On はユーザーを認証する。
  3. Red Hat Single Sign-On はトークンをアプリケーションに発行する。このアウリケーションは、Red Hat Single Sign-On に送信する認証要求の scope=<untrusted service> に配置されるように、信頼されていないサービスを呼び出す必要があることを認識しています (scope パラメーターの詳細は クライアントの範囲のセクション を参照)。

    アプリケーションに発行されたトークンには、対象範囲内の信頼できないサービスへの参照 ("audience": [ "<untrusted service>" ]) が含まれます。これで、クライアントがこのアクセストークンを使用して信頼できないサービスを呼び出すことを宣言します。

  4. 信頼されないサービスは、トークンを使用して信頼できるサービスを呼び出します。信頼できるサービスがトークンのオーディエンスをチェックし、そのオーディエンスが信頼できないサービスのみを対象としていることを検出したため、呼び出しは成功しません。これは想定内の動作であり、セキュリティーが破損していません。

クライアントが後で信頼されるサービスを呼び出す場合は、scope=<trusted service> で SSO ログインを再発行して別のトークンを取得する必要があります。返されるトークンには、信頼できるサービスが対象として含まれます。

"audience": [ "<trusted service>" ]

この値を使用して <trusted service> を起動します。

12.1.8.1. 設定

対象チェックを設定する場合は、以下を行います。

  • アダプター構成に verify-token-audience フラグを追加して、サービスが送信されたアクセストークンのオーディエンスを確認するように構成されていることを確認します。詳細は アダプターの設定 を参照してください。
  • Red Hat Single Sign-On が発行するアクセストークンに、必要な対象範囲がすべて含まれていることを確認します。オーディエンスは、次のセクション またはハードコーディングで説明されているように、クライアントロールを使用して追加できます。ハードコードされた対象範囲 を参照してください。

12.1.8.2. 対象の自動追加

Audience Resolve プロトコルマッパーは、デフォルトのクライアントスコープの ロール で定義されます。マッパーは、現在のトークンで使用可能なクライアントロールが少なくとも 1 つあるクライアントをチェックします。各クライアントのクライアント ID は対象として追加されます。これは、サービス(通常は Bearer のみ)クライアントがクライアントロールに依存する場合に便利です。

たとえば、Bearer のみのクライアントと機密クライアントの場合は、機密クライアント向けに発行されたアクセストークンを使用して Bearer のみのクライアント REST サービスを呼び出すことができます。Bearer のみクライアントは、以下が true の場合に、機密クライアント向けに発行されたアクセストークンの対象として自動的に追加されます。

  • Bearer のみのクライアントにはそれ自体で定義されたクライアントロールがある。
  • ターゲットユーザーには、少なくとも 1 つのクライアントロールが割り当てられている。
  • 機密クライアントには割り当てられたロールのロールスコープマッピングがある。
注記

対象が自動的に追加されないようにする場合は、機密クライアントに直接ロールスコープマッピングを設定しないでください。代わりに、専用のクライアントスコープのクライアントロールにロールスコープマッピングが含まれる専用のクライアントスコープを作成できます。

クライアントスコープが任意のクライアントスコープとし気密クライアントに追加されると、scope=<trusted service> パラメーターで明示的に要求されている場合は、クライアントロールと対象がトークンに追加されます。

注記

フロントエンドクライアント自体はアクセストークンオーディエンスに自動的に追加されないため、アクセストークンには、トークンが対象として発行されるクライアントが含まれないので、アクセストークンと ID トークンを簡単に区別できます。

クライアント自体をオーディエンスとして必要な場合は、ハードコーディングされたオーディエンスオプションを参照してください。ただし、フロントエンドと REST サービスと同じクライアントを使用することは推奨されていません。

12.1.8.3. ハードコードされたオーディエンス

サービスがレルムロールに依存する場合や、トークンのロールに依存しない場合は、ハードコーディングされた対象範囲を使用すると便利です。ハードコーディングされた対象範囲は、指定されたサービスクライアントのクライアント ID を対象としてトークンに追加するプロトコルマッパーです。クライアント ID 以外の対象を使用する場合は、URL などのカスタム値を使用できます。

プロトコルマッパーを直接フロントエンドクライアントに追加できます。プロトコルマッパーが直接追加されると、常に対象が追加されます。

プロトコルマッパーをより詳細に制御するには、 good-service などとして呼ばれる、専用のクライアントスコープでプロトコルマッパーを作成できます。

オーディエンスプロトコルマッパー

audience mapper

  • good-service クライアントの インストールタブ から、アダプタの構成を生成し、verify-token-audience オプションが true に設定されていることを確認できます。これにより、この設定を使用する場合にアダプターが対象を強制的に検証するようにします。
  • 機密クライアントがトークン内の対象として good-service を要求できます。

    機密クライアントで以下を行います。

    1. Client Scopes タブをクリックします。
    2. good-service をオプション (またはデフォルト) クライアント範囲として割り当てます。

      詳細は、「クライアントスコープのリンク」セクションを参照してください。

  • 必要に応じて、クライアントスコープを評価 し、サンプルアクセストークンを生成することができます。任意のクライアントスコープとして割り当てられた場合は、good-servicescope パラメーターに含まれている場合に、生成されるアクセストークンの対象者に good-service が追加されます。
  • 機密クライアントアプリケーションで、scope パラメーターが使用されていることを確認します。good-service にアクセスするためのトークンを発行する場合は、good-service の値を含める必要があります。

    参照:

注記

Audience および Audience Resolve プロトコルマッパーの両方はデフォルトで、対象をアクセストークンに追加します。ID トークンには通常、OpenID Connect 仕様の要件である単一の対象のみ (トークンが発行されたクライアント ID) が含まれます。ただし、アクセストークンには、対象マッパーが追加されない限り、トークンが発行されたクライアント ID があるとは限りません。