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

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

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

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

Logo URL

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

Policy URL

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

Terms of Service URL

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

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

OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled

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

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

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

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

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

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

OIDC の詳細設定

OpenID Connect の詳細設定を使用すると、クライアントレベルで セッションタイムアウトとトークンタイムアウト のオーバーライドを設定できます。

Proof Key for Code Exchange Code Challenge Method

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

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

詳細は、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 がサポートする鍵管理モードは、鍵の暗号化です。

キーの暗号化の場合:

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

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

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

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

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

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 動的クライアント登録仕様 を参照してください。

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

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

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

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

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

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

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

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

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

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

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

https://myhost.com/myapp/k_jwks

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

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

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

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

X509 証明書

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

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

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

アクセスタイプ が Confidential のクライアントの場合、Red Hat Single Sign-On は Client Policies を通じてクライアントシークレットをローテーションする機能をサポートします。

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

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

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

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

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

呼び出す 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

    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
}

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 にリクエストを送信して取り消すことができます。

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

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

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

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

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

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

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

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

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

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