Menu Close

第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 をクリックします。

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 を使用できます。詳細は、アプリケーションおよびサービスガイドを参照してください。
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 クライアントアダプターのみです。詳細は、アプリケーションおよびサービスガイドを参照してください。

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 プルダウンメニューからアルゴリズムを選択します。

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. 生成してダウンロード をクリックします。

これらのキーを生成すると、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. サービスアカウントの使用

各 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.6. オーディエンスのサポート

通常、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.6.1. 設定

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

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

12.1.6.2. 対象の自動追加

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

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

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

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

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

注記

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

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

12.1.6.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 があるとは限りません。