Menu Close
Settings Close

Language and Page Formatting Options

サーバー管理ガイド

Red Hat Single Sign-On 7.6

Red Hat Single Sign-On 7.6 向け

概要

本ガイドは、管理者が Red Hat Single Sign-On 7.6 を設定する情報で構成されています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。これは大規模な取り組みであるため、これらの変更は今後の複数のリリースで段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

第1章 Red Hat Single Sign-On の機能および概念

Red Hat Single Sign-On は、Web アプリケーションと RESTful Web サービスのソリューションに関するシングルサインオンです。Red Hat Single Sign-On の目的は、アプリケーション開発者が組織にデプロイしたアプリケーションおよびサービスのセキュリティーを保護することができるように、セキュリティーシンプルにすることです。通常、開発者は自分で作成する必要のあるセキュリティー機能は、追加設定なしで提供され、組織の個々の要件に簡単に調整できます。Red Hat Single Sign-On は、ログイン、登録、管理、アカウント管理用にカスタマイズ可能なユーザーインターフェースを提供します。Red Hat Single Sign-On を統合プラットフォームとして使用し、既存の LDAP サーバーと Active Directory サーバーへフックすることもできます。Facebook や Google などのサードパーティーアイデンティティープロバイダーに認証を委譲することもできます。

1.1. 機能

Red Hat Single Sign-On は、以下の機能を提供します。

  • ブラウザーアプリケーションには、Single-Sign On および Single-Sign Out です。
  • OpenID Connect のサポート。
  • OAuth 2.0 サポート。
  • SAML サポート。
  • ID ブローカー: 外部 OpenID Connect または SAML ID プロバイダーで認証されます。
  • ソーシャルログイン - Google、GitHub、JWT、その他のソーシャルネットワークでのログインを有効にします。
  • ユーザーフェデレーション: LDAP および Active Directory サーバーからユーザーを同期します。
  • Kerberos ブリッジ: Kerberos サーバーにログインしたユーザーを自動的に認証します。
  • ユーザー、ロール、ロールマッピング、クライアント、および設定の一元管理のための管理コンソール。
  • ユーザーがアカウントを一元管理できるアカウントマネジメントコンソール。
  • テーマサポート: アプリケーションおよびブランディングと統合するユーザー向けページのカスタマイズ。
  • 2 要素認証: Google Authenticator または FreeOTP による TOTP/HOTP のサポート
  • ログインフロー: オプションのユーザーの自己登録、パスワードのリカバリー、電子メールの確認、パスワードの更新など。
  • セッション管理: 管理者およびユーザー自身がユーザーセッションを表示および管理できます。
  • トークンマッパー: トークンとステートメントへのユーザーの属性、ロールなどをマップします。
  • レルム、アプリケーション、ユーザーごとの失効前ポリシー。
  • CORS サポート - クライアントアダプターには CORS のサポートが組み込まれています。
  • JavaScript アプリケーション、JBoss EAP などのクライアントアダプター。
  • OpenID Connect 依存パーティーライブラリーまたは SAML 2.0 サービスプロバイダーライブラリーを持つすべてのプラットフォーム/言語をサポートします。

1.2. Red Hat Single Sign-On の基本操作

Red Hat Single Sign-On は、ネットワーク上で管理する別のサーバーです。アプリケーションは、このサーバーによって提供され、保護されるように設定されています。Red Hat Single Sign-On は、OpenID Connect または SAML 2.0 などのオープンプロトコル標準を使用してアプリケーションを保護します。ブラウザーアプリケーションは、ユーザーのブラウザーをアプリケーションから Red Hat Single Sign-On 認証サーバーにリダイレクトし、ユーザーに認証情報の入力を求めます。ユーザーがアプリケーションから完全に分離され、アプリケーションにはユーザーの認証情報が確認されないため、このリダイレクトは重要です。アプリケーションには、暗号で署名された認証情報トークンまたはアサーションが与えられます。これらのトークンには、ユーザー名、アドレス、電子メール、他のプロファイルデータなどのアイデンティティー情報を使用できます。また、アプリケーションによる承認決定を実行できるように、パーミッションデータを保持することもできます。これらのトークンを使用して、REST ベースのサービスでセキュアな呼び出しを行うこともできます。

1.3. コアとなる概念および用語

Web アプリケーションおよび REST サービスを保護するために、Red Hat Single Sign-On の使用を試みる前に、これらのコアとなる概念と用語について検討してください。

users
ユーザーは、システムにログインできるエンティティーです。電子メール、ユーザー名、アドレス、電話番号、および日目などの属性を関連付けることができます。グループメンバーシップを割り当てることができ、特定のロールをそれらに割り当てることができます。
認証
ユーザーを特定し、検証するプロセスです。
認可
ユーザーに付与するプロセスです。
認証情報
認証情報は、Red Hat Single Sign-On がユーザーの ID を検証するために使用するデータの一部です。たとえば、パスワード、ワンタイムパスワード、デジタル証明書、またはフィンガープリントなどが挙げられます。
ロール
ロールはユーザーのタイプまたはカテゴリーを識別します。Adminusermanageremployee は、組織に存在する可能性のある通常のロールすべてです。アプリケーションは通常、多くの場合、個々のユーザーではなく、特定のロールにアクセスおよびパーミッションを割り当てます。これは、ユーザーの処理は複雑で、管理が困難となるためです。
ユーザーロールのマッピング
ユーザーロールのマッピングは、ロールとユーザー間のマッピングを定義します。ユーザーをゼロ以上のロールに関連付けることができます。このロールマッピング情報は、アプリケーションが管理するさまざまなリソースのアクセスパーミッションを決定することができるように、トークンとアサーションにカプセル化できます。
複合ロール
複合ロールは、他のロールに関連付けることができるロールです。たとえば、superuser の複合ロールを sales-admin ロールおよび order-entry-admin ロールに関連付けることができます。ユーザーが superuser ロールにマップされている場合は、sales-admin ロールおよび order-entry-admin ロールも継承されます。
グループ
グループはユーザーのグループを管理します。グループに対して属性を定義できます。ロールをグループにマッピングすることもできます。グループのメンバーになるユーザーは、そのグループで定義される属性とロールマッピングを継承します。
レルム
レルムは、一連のユーザー、認証情報、ロール、およびグループを管理します。ユーザーはレルムに属し、レルムにログインします。レルムは相互に分離され、制御するユーザーのみを管理および認証できます。
クライアント
クライアントは、Red Hat Single Sign-On を要求してユーザーを認証できるエンティティーです。多くの場合、クライアントは Red Hat Single Sign-On を使用して自己保護し、シングルサインオンソリューションを提供するアプリケーションとサービスです。クライアントは、ID 情報またはアクセストークンを要求するエンティティーで、Red Hat Single Sign-On によってセキュア化されるネットワーク上でその他のサービスを安全に呼び出すことができるようにすることもできます。
クライアントアダプター
クライアントアダプターは、アプリケーション環境にインストールするプラグインで、Red Hat Single Sign-On の通信およびセキュア化を可能にします。Red Hat Single Sign-On には、ダウンロード可能なさまざまなプラットフォームに多くのアダプターがあります。また、サードパーティーのアダプターも、対象外の環境で取得できます。
consent
Consent は、クライアントが認証プロセスに参加する前に、ユーザーにクライアントにパーミッションを付与する場合です。ユーザーがクレデンシャルを提供すると、Red Hat Single Sign-On がログインを要求するクライアントを特定する画面と、ユーザーの要求情報を確認する画面が表示されます。ユーザーは、要求を付与するかどうかを決定できます。
クライアントスコープ
クライアントが登録されたら、そのクライアントのプロトコルマッパーとロールスコープマッピングを定義する必要があります。多くの場合、クライアントスコープを保存し、共通の設定を共有することで新しいクライアントの作成を簡素化します。これは、一部の要求またはロールを scope パラメーターの値に基づいて条件付きで要求する場合にも便利です。Red Hat Single Sign-On では、このクライアントスコープの概念が提供されています。
クライアントロール
クライアントは、それら固有のロールを定義できます。これは基本的に、クライアント専用のロール名前空間です。
ID トークン
ユーザーに関する情報を提供するトークン。OpenID Connect 仕様の一部。
アクセストークン
呼び出されるサービスへのアクセスを付与する HTTP リクエストの一部として提供できるトークン。これは、OpenID Connect および OAuth 2.0 仕様の一部です。
アサーション
ユーザーに関する情報。これは通常、認証されたユーザーに関連するアイデンティティーメタデータを提供する SAML 認証応答に含まれる XML Blob に関連します。
サービスアカウント
各クライアントには、アクセストークンの取得を可能にする組み込み service account があります。
直接付与
REST 呼び出しでユーザーの代わりにアクセストークンを取得する方法。
プロトコルマッパー
各クライアントについて、OIDC トークンまたは SAML アサーションに保存される要求とアサーションを調整できます。プロトコルマッパーを作成および設定して、クライアントごとにこれを行います。
セッション
ユーザーがログインすると、セッションがログインセッションを管理します。セッションには、ユーザーがログインした時や、そのセッション中に単一署名に参加したアプリケーションなどの情報が含まれます。管理者およびユーザーの両方がセッション情報を表示できます。
ユーザーフェデレーションプロバイダー
Red Hat Single Sign-On はユーザーを保存して管理できます。多くの場合、ユーザーと認証情報を格納する LDAP または Active Directory サービスがすでにあります。Red Hat Single Sign-On を示すことで、外部ストアから認証情報を検証して ID 情報にプルすることができます。
アイデンティティープロバイダー
アイデンティティープロバイダー (IDP) はユーザーを認証できるサービスです。Red Hat Single Sign-On は IDP です。
ID プロバイダーフェデレーション
Red Hat Single Sign-On は、1 つ以上の IDP に認証を委譲するように設定できます。Facebook または Google+ でのソーシャルログインは、アイデンティティープロバイダーのフェデレーションの例です。また、Red Hat Single Sign-On のフックを行い、認証を他の OpenID Connect または SAML 2.0 IDP に委任することもできます。
アイデンティティープロバイダーマッパー
IDP フェデレーションを行う場合は、受信したトークンとアサーションを user および session 属性にマッピングできます。これは、外部の IDP から認証を要求するクライアントに ID 情報を伝播するのに役立ちます。
必要なアクション
必要なアクションは、ユーザーが認証プロセス中に実行する必要のあるアクションです。ユーザーは、これらのアクションが完了するまで認証プロセスを完了できません。たとえば、管理者はユーザーが毎月パスワードをリセットできるようにスケジュールすることが可能です。これらの全ユーザーに対して、update password に必要なアクションが設定されます。
認証フロー
認証フローは、システムの特定の側面と対話するときにユーザーが実行する必要のあるフローです。ログインフローは必要な認証情報タイプを定義できます。登録フローは、ユーザーが入力しなければならないプロファイル情報や、ボットをフィルターするのに reCAPTCHA などのプロファイル情報を定義します。認証情報リセットフローは、パスワードをリセットする前にユーザーが行うべきアクションを定義します。
イベント
イベントは、管理者が表示やフックを表示できる監査ストリームです。
テーマ
Red Hat Single Sign-On が提供するすべての画面は、テーマでサポートされます。テーマは、必要に応じて上書きできる HTML テンプレートとスタイルシートを定義します。

第2章 最初の管理者の作成

Red Hat Single Sign-On のインストール後に、Red Hat Single Sign-On のすべての部分を管理するため、完全なメーションで super 管理者として動作できる管理者アカウントが必要です。このアカウントで、レルムおよびユーザーを作成し、Red Hat Single Sign-On でセキュア化されたアプリケーションを登録する Red Hat Single Sign-On 管理コンソールにログインすることができます。

前提条件

2.1. ローカルホストでのアカウントの作成

サーバーが localhost からアクセスできる場合は、以下の手順を実行します。

手順

  1. Web ブラウザーで、http://localhost:8080/auth URL に移動します。
  2. 再呼び出しできるユーザー名とパスワードを指定します。

    Welcome ページ

    Welcome Page

2.2. リモートでアカウントの作成

localhost アドレスからサーバーにアクセスできない場合や、コマンドラインから Red Hat Single Sign-On を起動する必要がある場合は、…​/bin/add-user-keycloak スクリプトを使用します。

add-user-keycloak スクリプト

add user script

スタンドアロン操作モードまたはドメイン操作モードを使用している場合によって、パラメーターはほとんど異なります。スタンドアロンモードの場合、ここではスクリプトの使用方法を紹介します。

Linux/Unix

$ .../bin/add-user-keycloak.sh -r master -u <username> -p <password>

Windows

> ...\bin\add-user-keycloak.bat -r master -u <username> -p <password>

ドメインモードでは、-sc スイッチを使用して、スクリプトがサーバーホストの 1 つを参照するようにする必要があります。

Linux/Unix

$ .../bin/add-user-keycloak.sh --sc domain/servers/server-one/configuration -r master -u <username> -p <password>

Windows

> ...\bin\add-user-keycloak.bat --sc domain/servers/server-one/configuration -r master -u <username> -p <password>

第3章 レルムの設定

管理コンソールの管理者アカウントを取得したら、レルムを設定できます。レルムは、ユーザー、アプリケーション、ロール、グループなどのオブジェクトを管理するスペースです。ユーザーはレルムに属し、レルムにログインします。Red Hat Single Sign-On のデプロイメント 1 つで、データベースに多くのレルムを定義、保存、および管理できます。

3.1. 管理コンソールの使用

レルムを設定し、Red Hat Single Sign-On 管理コンソールでほとんどの管理タスクを実行します。

前提条件

手順

  1. 管理コンソールの URL に移動します。

    たとえば、ローカルホストの場合は、URL http://localhost:8080/auth/admin/ を使用します。

    ログインページ

    Login page

  2. Welcome Page で作成したユーザー名やパスワードを入力するか、bin ディレクトリーに add-user-keycloak スクリプトを入力します。このアクションは管理コンソールを表示します。

    管理コンソール

    Admin Console

  3. 使用可能なメニューおよびその他のオプションに注意してください。

    • Master というラベルのメニューをクリックし、管理するレルムを選択するか、または新規レルムを作成します。
    • 右上の一覧をクリックしてアカウントを表示するか、またはログアウトします。
    • 疑問符 ? アイコンにカーソルを合わせ、そのフィールドを記述するツールチップテキストを表示します。上記のイメージはアクションのツールチップを示しています。

3.2. マスターレルム

管理コンソールでは、2 種類のレルムが存在します。

  • Master realm: このレルムは、Red Hat Single Sign-On の初回起動時に作成されました。これには、初回ログイン時に作成した管理者アカウントが含まれます。マスター レルムのみを使用して、システムでレルムを作成および管理します。
  • 他のレルム: マスターレルムの管理者が、これらのレルムが作成されます。管理者は、これらのレルムで、組織と必要なアプリケーションのユーザーを管理します。アプリケーションはユーザーが所有します。

レルムおよびアプリケーション

Realms and applications

レルムは相互に分離され、制御するユーザーのみを管理および認証できます。このセキュリティーモデルに従うことで、誤って変更を回避し、ユーザーアカウントのクリメンティションに従って、現在のタスクの正常な完了に必要な特権と電源へのアクセスを許可します。

関連情報

  • マスター レルムを無効にし、作成する新しいレルムに管理者アカウントを定義する場合は、「Dedicated Realm Admin Consoles」を参照してください。各レルムには独自の専用管理コンソールがあり、ローカルアカウントでログインできます。

3.3. レルムの作成

レルムを作成して、ユーザーを作成し、アプリケーションを使用するパーミッションを付与できる管理スペースを提供します。初回ログイン時に、通常は マスター レルム (他のレルムを作成する最上位のレルム) です。

必要なレルムを決定する際には、ユーザーおよびアプリケーションに必要な分離の種類を考慮してください。たとえば、所属企業の従業員および顧客向けに別のレルムにレルムを作成することができます。従業員は従業員のレルムにログインし、内部の会社アプリケーションにしかアクセスできません。顧客が顧客のレルムにログインし、顧客がアクセスするアプリケーションと対話することしかできません。

手順

  1. 左側のペインの上部を示します。
  2. レルムの追加 をクリックします。

    レルムメニューの追加

    Add realm menu

  3. レルムの名前を入力します。
  4. Create をクリックします。

    レルムの作成

    Create realm

これで、現在のレルムが作成したレルムに設定されます。左上隅を参照して異なるレルムの管理を切り換えて、Select Realm をクリックします。

3.4. レルムでの SSL の設定

各レルムには関連する SSL モードがあり、レルムと対話するための SSL/HTTPS 要件を定義します。レルムと相互作用するブラウザーとアプリケーションは、SSL モードで定義された SSL/HTTPS 要件を有効にするか、サーバーと対話できません。

警告

Red Hat Single Sign-On は、初回実行時に自己署名証明書を生成します。自己署名証明書は安全ではなく、テスト目的でのみ使用する必要があることに注意してください。Red Hat Single Sign-On サーバー自体またはリバースプロキシーに CA 署名の証明書をインストールすることを、Red Hat Single Sign-On サーバーの前にインストールすることが強く推奨されます。サーバーインストールおよび設定ガイドを参照してください。

手順

  1. メニューで Realm Settings をクリックします。
  2. Login タブをクリックします。

    ログインタブ

    Login tab

  3. Require SSL を、以下の SSL モードのいずれかに設定します。

    • 外部リクエスト: ユーザーは SSL なしで Red Hat Single Sign-On と対話できるので、localhost127.0.0.110.x.x.x192.168.x.x172.16.x.x などのプライベート IP アドレスに留まる場合に限ります。非プライベート IP アドレスから SSL なしで Red Hat Single Sign-On にアクセスしようとすると、エラーが発生します。
    • none:: Red Hat Single Sign-On には SSL は必要ありません。この選択肢は、実験時にのみ適用され、このデプロイメントをサポートする予定はありません。
    • すべてのリクエスト:: Red Hat Single Sign-On では、すべての IP アドレスに SSL が必要です。

3.5. サーバーキャッシュの消去

Red Hat Single Sign-On は、JVM の制限と設定した制限の範囲内で、メモリー内のメモリーにあるものをすべてキャッシュします。サーバーの REST API または管理コンソールの範囲外の DBA などのサードパーティーによって Red Hat Single Sign-On データベースが変更された場合は、インメモリーキャッシュの一部が古くなる可能性があります。レルムキャッシュ、ユーザーキャッシュ、または外部公開鍵 (外部クライアントまたはアイデンティティープロバイダーの公開鍵など) を消去できます。Red Hat Single Sign-On は、特定の外部エンティティーの署名の検証に使用できます。

手順

  1. メニューで Realm Settings をクリックします。
  2. Cache タブをクリックします。
  3. エビクトするキャッシュの Clear をクリックします。

    キャッシュタブ

    Cache tab

3.6. レルムへのメールの設定

Red Hat Single Sign-On は、電子メールをユーザーに送信し、パスワードの取得時、または管理者がサーバーイベントに関する通知を受け取る必要がある場合に、メールアドレスを確認します。Red Hat Single Sign-On がメールを送信できるようにするには、Red Hat Single Sign-On に SMTP サーバー設定を提供します。

手順

  1. メニューで Realm Settings をクリックします。
  2. Email タブをクリックします。

    Email tab

    Email Tab

  3. フィールドに入力し、必要に応じてスイッチを切り替えます。

    Host
    ホストは、電子メールの送信に使用される SMTP サーバーのホスト名を示します。
    Port
    Port は SMTP サーバーポートを示します。
    From
    from は、送信メールに From SMTP ヘッダーに使用されるアドレスを示します。
    From Display Name
    ディスプレイ名 から、ユーザーフレンドリーなメールアドレスエイリアス (オプション) を設定できます。設定されていない場合、プレーン From のメールアドレスが電子メールクライアントに表示されます。
    Reply To
    Reply To は、送信メールの Reply-To SMTP-Header に使用されるアドレス (任意) を示します。設定されていない場合、プレーン From メールアドレスが使用されます。
    Reply To Display Name
    ディスプレイ名への返信 により、ユーザーフレンドリーなメールアドレスエイリアス (オプション) を設定できます。設定しない場合には、プレーンな Reply To のメールアドレスが表示されます。
    Envelope From
    From は、送信メールの Return-Path Header に使用される Bounce Address アドレスを示します(任意)。
    SSL の有効化および StartTSL の有効化
    これらのスイッチの 1 つを オン に切り替えることで、特に SMTP サーバーが外部ネットワーク上にある場合は、ユーザー名とパスワードを回復するための電子メールの送信をサポートします。多くの場合、ポート を SSL/TLS のデフォルトポートである 465 に変更する必要がございます。
    認証の有効化
    SMTP サーバーで認証が必要な場合は、このスイッチを ON に設定します。プロンプトが表示されたら、Username および Password を指定します。Password フィールドの値は、外部 vault からの値を参照できます。

3.7. テーマと国際化の設定

指定のレルムの場合は、Red Hat Single Sign-On で、表示する言語など、UI の外観を変更できます。

手順

  1. メニューで Realm Setting をクリックします。
  2. Themes タブをクリックします。

    themes タブ

    Themes tab

  3. 各 UI カテゴリーに対して必要なテーマを選択し、Save をクリックします。

    ログインテーマ
    ユーザー名エントリー、OTP エントリー、新しいユーザー登録、およびその他の同様の画面。
    アカウント: テーマ
    各ユーザーに、ユーザーアカウントの管理 UI があります。
    管理コンソールのテーマ
    Red Hat Single Sign-On 管理コンソールのスキン。
    メールテーマ
    Red Hat Single Sign-On がメールを送信する必要がある場合には、このテーマに定義されているテンプレートを使用して電子メールを作成します。

関連情報

  • Server Developer Guide では、新しいテーマの作成方法や既存のテーマの変更方法について説明します。

3.7.1. 国際化の有効化

すべての UI 画面は、Red Hat Single Sign-On で国際化されています。デフォルトの言語は英語ですが、使用するロケールや、デフォルトのロケールを選択できます。

手順

  1. メニューで Realm Settings をクリックします。
  2. Theme タブをクリックします。
  3. 国際化ON に設定します。

ユーザーが次回ログインすると、そのユーザーはログインページの言語を選択して、ログイン画面、Account Console、および Admin Console に使用できます。

関連情報

  • Server Developer Guide では、追加の言語を提供する方法を説明します。テーマによって提供されるすべての国際化されたテキストは、ローカライゼーション タブでレルム固有のテキストによって上書きできます。

3.7.2. ユーザーロケールの選択

ロケールセレクタープロバイダーは、利用可能な情報に関する最適なロケールを提案します。ただし、多くの場合は、ユーザーに不明です。このため、以前に認証されたユーザーのロケールは永続化されたクッキーに記憶されます。

ロケールを選択するには、以下の最初の項目を使用します。

  • User selected: ドロップダウンロケールセレクターを使用してロケールを選択するとき
  • User profile: 認証されたユーザーがあり、ユーザーにロケールセットが推奨されるとき
  • Client selected: ui_locales パラメーターなどを使用してクライアントにより渡される
  • Cookie: ブラウザーで選択した最後のロケール
  • 許可される言語: Accept-Language ヘッダーからのロケール
  • レルムのデフォルト
  • 上記のいずれでなければ、英語に戻ります。

ユーザーが認証されたとき、アクションがトリガーされ、前述の永続化されたクッキーでロケールを更新します。ユーザーがログインページのロケールセレクターでロケールをアクティブに切り替える場合は、この時点でユーザーロケールも更新されます。

ロケールを選択するロジックを変更する場合は、LocaleSelectorProvider を作成するオプションがあります。詳細は、サーバー開発者ガイドを参照してください。

3.8. ログインオプションの制御

Red Hat Single Sign-On には、複数の組み込みログインページ機能が含まれています。

3.8.1. forgot password 有効化

Forgot Password を有効にすると、パスワード を取得するか、OTP ジェネレーターを失う場合に、ログイン認証情報をリセットできます。

手順

  1. メニューで Realm Settings をクリックします。
  2. Login タブをクリックします。

    ログインタブ

    Login Tab

  3. Forgot PasswordON に切り替えます。

    forgot password リンクがログインページに表示されます。

    forgot password リンク

    Forgot Password Link

  4. このリンクをクリックして、ユーザー名またはメールアドレスを入力し、リンクのある電子メールを受信して認証情報をリセットできるユーザーを追加します。

    Forgot password ページ

    Forgot Password Page

メールで送信されるテキストは設定可能です。詳細は、サーバー開発者ガイドを参照してください。

ユーザーがメールリンクをクリックすると、Red Hat Single Sign-On によりパスワードが更新され、OTP ジェネレーターを設定している場合は、Red Hat Single Sign-On により OTP ジェネレーターが再設定するよう要求されます。組織のセキュリティー要件によっては、ユーザーが電子メールで OTP ジェネレーターをリセットしたくないことがあります。

この動作を変更するには、以下の手順を実施します。

手順

  1. メニューで Authentication をクリックします。
  2. Flows タブをクリックします。
  3. Reset Credentials フローを選択します。

    認証情報フローをリセット

    Reset Credentials Flow

    OTP をリセットしない場合は、Reset OTP の要件を Disabled に設定します。

  4. Required Actions タブをクリックします。Update Password が有効になっていることを確認します。

3.8.2. Remember Me の有効化

ブラウザーを閉じたログインユーザーはセッションを破棄し、そのユーザーは再度ログインする必要があります。ログイン時に Remember Me チェックボックスをクリックし、ユーザーのログインセッションを開いたままに Red Hat Single Sign-On を設定できます。このアクションは、ログインクッキーをセッションのみのクッキーから永続クッキーに変換します。

手順

  1. メニューで Realm Settings をクリックします。
  2. Login タブをクリックします。
  3. Remember MeON に切り替えます。

    ログインタブ

    login tab

この設定を保存すると、レルムのログインページに remember me チェックボックスが表示されます。

Remember Me

remember me

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

レルムのログイン設定では、どの Authentication Context Class Reference (ACR) 値をどの Level of Authentication (LoA) マップするかを定義できます。ACR には任意の値を指定できますが、LA は数値でなければなりません。acr 要求は、OIDC 要求で送信される claim または acr_values パラメーターで要求でき、アクセストークンおよび ID トークンにも含めることができます。マッピングされた番号は、認証フロー条件で使用されます。

特定のクライアントがレルムとは異なる値を使用する必要がある場合は、マッピングをクライアントレベルで指定することもできます。ただし、レルムマッピングを行うのがベストプラクティスです。

ACR to LoA mapping

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

3.8.3.1. 電子メールワークフローの更新 (UpdateEmail)

このワークフローでは、ユーザーは UPDATE_EMAIL アクションを使用して独自のメールアドレスを変更する必要があります。

アクションは、単一のメール入力フォームに関連付けられます。レルムの電子メール検証が無効な場合は、この動作により、検証なしに電子メールを更新できます。レルムで電子メールの検証が有効になっている場合は、アカウントメールを変更せずにアクションが新しいメールアドレスにメール更新アクショントークンを送信します。トリガーされるアクショントークンのみがメールの更新を完了します。

アプリケーションは UPDATE_EMAIL を AIA (Application Initiated Action) として利用することで、ユーザーをメール更新フォームに送信できます。

注記

UpdateEmail は テクノロジープレビュー であるため、完全にサポートされていません。この機能はデフォルトで無効にされています。

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

注記

この機能を有効にして、以前のバージョンから移行する場合は、レルムで 電子メールの更新に必要なアクションを有効にします。そうでない場合は、メールアドレスを更新できません。

3.9. レルムキーの設定

Red Hat Single Sign-On によって使用される認証プロトコルには、暗号化署名が必要になり、暗号化時があります。Red Hat Single Sign-On では、非対称鍵のペア (秘密鍵と公開鍵) を使用してこれを実現します。

Red Hat Single Sign-On には、同時にアクティブなキーペアが 1 つ含まれますが、複数のパッシブキーを持つこともできます。アクティブなキーペアは新規署名の作成に使用されますが、パッシブキーペアを使用して以前の署名を検証することができます。これにより、ダウンタイムやユーザーの中断なしにキーを定期的にローテーションできます。

レルムがキーペアが作成されると、自己署名証明書が自動的に生成されます。

手順

  1. 管理コンソールでレルムを選択します。
  2. Realm settings をクリックします。
  3. Keys をクリックします。
  4. Passive 鍵を表示するには、Passive をクリックします。
  5. Disabled をクリックして無効なキーを表示します。

キーペアにはステータスが Active になりますが、現在レルムにアクティブなキーペアとして選択されません。署名に使用される選択したアクティブなペアは、優先度別にソートされた最初のキープロバイダーに基づいて選択され、アクティブなキーペアを提供できます。

3.9.1. 鍵のローテーション

鍵を定期的にローテーションすることが推奨されます。これには、最初に、既存のアクティブなキーよりも優先度が高い新しいキーを作成します。または、同じ優先順位で新しいキーを作成し、以前のキーパッシブを作成します。

新しい鍵が利用可能になると、新しいトークンと cookie はすべて新しいキーで署名されます。ユーザーがアプリケーションに対して認証されると、SSO クッキーは新しい署名で更新されます。OpenID Connect トークンを更新すると、新しいキーで新たなトークンが署名されます。つまり、時間が経過するとすべての Cookie とトークンが新しいキーを使用し、古いキーを削除できる間に続きます。

古いキーを削除する頻度は、セキュリティー間のトレードオフであり、すべてのクッキーとトークンが更新されるようにすることです。新しいキーの作成後に、3 カ月から 6 カ月までのすべてのキーを作成し、古いキーを 2 カ月に削除することを検討してください。新しいキーが追加され、古いキーが削除されるまでの期間にユーザーが非アクティブである場合、そのユーザーは再認証する必要があります。

鍵をローテーションすると、オフライントークンにも適用されます。これらのアプリケーションが古いキーが削除される前にトークンを更新する必要のあることを確認するには、アプリケーションを更新します。

3.9.2. 生成されたキーペアの追加

手順

  1. 管理コンソールでレルムを選択します。
  2. Realm settings をクリックします。
  3. Keys タブをクリックします。
  4. Providers タブをクリックします。
  5. Add keystore をクリックし、rsa-generated を選択します。
  6. Priority フィールドに番号を入力します。この数字は、新しいキーペアがアクティブなキーペアになるかどうかを決定します。
  7. keysize の値を選択します。
  8. Save をクリックします。

このアクションにより、自己署名証明書を含む新しいキーペアが生成されます。

プロバイダーの優先度を変更すると、キーが再生成されますが、キーサイズを変更する場合はプロバイダーを編集し、新しいキーが生成されます。

3.9.3. 既存のキーペアおよび証明書の追加

別のユーザーが取得したキーペアと証明書を追加し、Providers を選択し、ドロップダウンから rsa を選択します。新たなキーペアがアクティブなキーペアになるように、優先度を変更することができます。

前提条件

  • プライベートキーファイル。ファイルは PEM 形式である必要があります。

手順

  1. 管理コンソールでレルムを選択します。
  2. Realm settings をクリックします。
  3. Keys タブをクリックします。
  4. Providers タブをクリックします。
  5. Add keystore をクリックし、rsa を選択します。
  6. Priority フィールドに番号を入力します。この数字は、新しいキーペアがアクティブなキーペアになるかどうかを決定します。
  7. Private RSA Key の横にある Select file をクリックして、秘密鍵ファイルをアップロードします。
  8. 秘密鍵に署名済みの証明書がある場合は、X509 Certificate の横にある Select file をクリックして、証明書ファイルをアップロードします。Red Hat Single Sign-On は、証明書をアップロードしない場合に自己署名証明書を生成します。
  9. Save をクリックします。

3.9.4. Java キーストアからキーを読み込む

ホストの Java キーストアファイルに保存されている鍵と証明書を追加するには、Provider を選択し、ドロップダウンから java-keystore を選択します。新たなキーペアがアクティブなキーペアになるように、優先度を変更することができます。

関連する証明書チェーンをロードするには、キーペアのロードに使用したものと同じ Key Aliasを使用して Java キーストアファイルにインポートする必要があります。

手順

  1. 管理コンソールでレルムを選択します。
  2. Realm settings をクリックします。
  3. Keys タブをクリックします。
  4. Providers タブをクリックします。
  5. Add keystore をクリックし、java-keystore を選択します。
  6. Priority フィールドに番号を入力します。この数字は、新しいキーペアがアクティブなキーペアになるかどうかを決定します。
  7. キーストア の値を入力します。
  8. キーストアパスワード の値を入力します。
  9. Key Alias の値を入力します。
  10. Key Password の値を入力します。
  11. Save をクリックします。

3.9.5. 鍵のパッシブの作成

手順

  1. 管理コンソールでレルムを選択します。
  2. Realm settings をクリックします。
  3. Keys タブをクリックします。
  4. Active タブをクリックします。
  5. パッシブに設定するキーのプロバイダーをクリックします。
  6. ActiveOFF に切り替えます。
  7. Save をクリックします。

3.9.6. キーの無効化

手順

  1. 管理コンソールでレルムを選択します。
  2. Realm settings をクリックします。
  3. Keys タブをクリックします。
  4. Active タブをクリックします。
  5. パッシブに設定するキーのプロバイダーをクリックします。
  6. EnabledOFF に切り替えます。
  7. Save をクリックします。

3.9.7. 侵害された鍵

Red Hat Single Sign-On にはローカルに保存された署名キーがあり、クライアントアプリケーション、ユーザー、またはその他のエンティティーと共有されることはありません。ただし、レルム署名鍵が不正であると思われる場合は、上記のように最初に新しいキーペアを生成し、不正アクセスのキーペアを即座に削除する必要があります。

または、プロバイダーを Providers テーブルから削除できます。

手順

  1. メニューで Clients をクリックします。
  2. security-admin-console をクリックします。
  3. Revocation タブをクリックします。
  4. Set to now をクリックします。
  5. Push をクリックします。

not-before ポリシーをプッシュすると、クライアントアプリケーションは、セキュリティー侵害を受けたキーで署名された既存のトークンを受け入れないようにします。クライアントアプリケーションは、Red Hat Single Sign-On から新しいキーペアをダウンロードするように強制され、不正アクセスされた鍵で署名されたトークンが無効になります。

注記

REST および confidential クライアントは Admin URL を設定して、Red Hat Single Sign-On がプッシュされた not-before ポリシー要求にクライアントを送信できます。

第4章 外部ストレージの使用

組織には、情報、パスワード、およびその他の認証情報が含まれるデータベースを設定できます。通常、既存のデータストレージを Red Hat Single Sign-On デプロイメントに移行することはできません。そのため、Red Hat Single Sign-On は既存の外部ユーザーデータベースをフェデレーションすることができます。Red Hat Single Sign-On は LDAP および Active Directory をサポートしますが、Red Hat Single Sign-On User Storage SPI を使用して、カスタムユーザーデータベースの拡張コードを使用することもできます。

ユーザーがログインを試みる際に、Red Hat Single Sign-On はそのユーザーのストレージを調べてそのユーザーを検索します。Red Hat Single Sign-On がユーザーを見つけられない場合、Red Hat Single Sign-On は、一致を見つけるまでレルムについて各 User Storage プロバイダーに対して繰り返し処理します。その後、外部データストレージからのデータは、Red Hat Single Sign-On ランタイムが消費する標準ユーザーモデルにマッピングします。次に、このユーザーモデルは OIDC トークンクレームと SAML アサーション属性にマッピングします。

外部ユーザーグループには、Red Hat Single Sign-On のすべての機能に対応するのに必要なデータはほとんどありません。そのため、User Storage Provider は Red Hat Single Sign-On のユーザーデータストレージに項目をローカルに保存できます。プロバイダーは、ユーザーをローカルでインポートして、外部データストレージと定期的に同期できます。この方法は、プロバイダーの機能とプロバイダーの設定によって異なります。たとえば、外部ユーザーデータのストレージは OTP に対応していない可能性があります。OTP はプロバイダーに応じて Red Hat Single Sign-On が処理して保存できます。

4.1. プロバイダーの追加

ストレージプロバイダーを追加するには、以下の手順を実行します。

手順

  1. メニューの User Federation をクリックします。

    ユーザーフェデレーション

    User federation

  2. Add Provider 一覧からプロバイダータイプを選択します。Red Hat Single Sign-On では、プロバイダーの設定ページに移動します。

4.2. プロバイダーの失敗の処理

User Storage Provider が失敗すると、ログインできず、管理コンソールでユーザーを表示できます。ストレージプロバイダーを使用してユーザーを検索するときに、Red Hat Single Sign-On は失敗を検出しないため、呼び出しを取り消します。ユーザーのルックアップ時に失敗する優先度が高いストレージプロバイダーの場合、ログインまたはユーザークエリーは例外を出して失敗し、次の設定されたプロバイダーにはフェイルオーバーしません。

Red Hat Single Sign-On は、最初にローカルの Red Hat Single Sign-On ユーザーデータベースを検索し、LDAP またはカスタムユーザーストレージプロバイダーの前にユーザーを解決します。LDAP およびバックエンドへの接続に問題がある場合は、ローカルの Red Hat Single Sign-On ユーザーデータベースに保存された管理者アカウントを作成することを検討してください。

各 LDAP およびカスタム User Storage Provider には、管理コンソールページで enable することができます。User Storage Provider を無効にすると、クエリーの実行時にプロバイダーがスキップされるので、優先度の低い別のプロバイダーでユーザーアカウントを表示し、ログインすることができます。プロバイダーが import ストラテジーを使用し、無効にされている場合、インポートユーザーは読み取り専用モードでも検索できます。

Storage Provider ルックアップが失敗すると、ユーザーデータベースにユーザー名が重複したり、メールが重複したりするため、Red Hat Single Sign-On はフェイルオーバーしません。ユーザー名とメールアドレスの重複により、管理者が別のデータストアからロードされることを想定した場合にユーザーが外部データストアからロードされるため、問題が発生する可能性があります。

4.3. LDAP (Lightweight Directory Access Protocol) および Active Directory

Red Hat Single Sign-On には LDAP/AD プロバイダーが含まれます。1 つの Red Hat Single Sign-On レルムで複数の LDAP サーバーをフェデレーションし、LDAP ユーザー属性を Red Hat Single Sign-On 共通ユーザーモデルにマッピングすることができます。

デフォルトでは、Red Hat Single Sign-On は、ユーザーアカウントのユーザー名、メール、名、および姓をマッピングしますが、追加の マッピング を設定することもできます。Red Hat Single Sign-On の LDAP/AD プロバイダーは、LDAP/AD プロトコルおよびストレージ、編集、同期モードを使用したパスワード検証をサポートします。

4.3.1. フェデレーションされた LDAP ストレージの設定

手順

  1. メニューの User Federation をクリックします。

    ユーザーフェデレーション

    User federation

  2. Add Provider 一覧から ldap を選択します。Red Hat Single Sign-On では、LDAP 設定ページに移動します。

4.3.2. ストレージモード

Red Hat Single Sign-On は、LDAP からローカルの Red Hat Single Sign-On ユーザーデータベースにユーザーをインポートします。このユーザーデータベースのコピーは、オンデマンドまたは定期的なバックグラウンドタスクを介して同期します。パスワード同期の例外が存在します。Red Hat Single Sign-On はパスワードをインポートしません。パスワードの検証は LDAP サーバーで常に行われます。

同期の利点は、必要な追加の追加のデータがローカルで保存されるため、すべての Red Hat Single Sign-On 機能を効率的に機能させることです。欠点は、Red Hat Single Sign-On が特定のユーザーに初めてクエリーを実行するたびに、Red Hat Single Sign-On に対応するデータベースの挿入を実行することです。

インポートを LDAP サーバーと同期できます。LDAP マッパーがデータベースではなく LDAP から特定の属性を常に読み取る場合、インポート同期は必要ありません。

ユーザーを Red Hat Single Sign-On ユーザーデータベースにインポートせずに、Red Hat Single Sign-On で LDAP を使用できます。LDAP サーバーは、Red Hat Single Sign-On ランタイムが使用する共通のユーザーモデルをバックアップします。LDAP が Red Hat Single Sign-On 機能が必要とするデータをサポートしない場合、その機能は動作しません。このアプローチの利点は、LDAP ユーザーのコピーを Red Hat Single Sign-On ユーザーデータベースにインポートおよび同期するリソース使用を持たないことです。

LDAP 設定ページの Import Users スイッチは、このストレージモードを制御します。ユーザーをインポートするには、この切り替えを ON に切り替えます。

注記

ユーザーのインポート を無効にすると、Red Hat Single Sign-On データベースにユーザープロファイル属性を保存できません。また、LDAP にマッピングされたユーザープロファイルメタデータ以外のメタデータを保存することはできません。このメタデータには、LDAP マッパーの設定に基づくロールマッピング、グループマッピング、およびその他のメタデータを含めることができます。

LDAP 以外のマッピングユーザーデータを変更しようとすると、ユーザーの更新ができません。たとえば、ユーザーの enabled フラグが LDAP 属性にマッピングされていない限り、LDAP マッピングされたユーザーを無効にすることはできません。

4.3.3. モードの編集

ユーザーおよび管理者は、管理コンソールからユーザーメタデータ、ユーザー Account Console および管理者が変更できます。LDAP 設定ページの Edit Mode 設定により、ユーザーの LDAP 更新権限が定義されます。

READONLY
ユーザー名、メール、名、姓、他のマップされた属性を変更することはできません。Red Hat Single Sign-On は、ユーザーがこれらのフィールドの更新を試みる際にエラーが表示されます。パスワードの更新はサポートされていません。
WRITABLE
ユーザー名、メール、名、姓、他のマップされた属性を変更し、LDAP ストアと自動的に同期することはできません。
未同期
Red Hat Single Sign-On では、Red Hat Single Sign-On のローカルストレージのユーザー名、メール、名、姓、およびパスワードへの変更が保存され、管理者はこのデータを LDAP に戻す必要があります。このモードでは、Red Hat Single Sign-On デプロイメントでは、読み取り専用 LDAP サーバーでユーザーメタデータを更新できます。このオプションは、LDAP からローカルの Red Hat Single Sign-On ユーザーデータベースにユーザーをインポートする場合にも適用されます。
注記

Red Hat Single Sign-On が LDAP プロバイダーを作成すると、Red Hat Single Sign-On は初期 LDAP マッパーのセットも作成します。Red Hat Single Sign-On は、VendorEdit Mode、および Import Users スイッチの組み合わせに基づいてこれらのマッパーを設定します。たとえば、編集モードが UNSYNCED の場合、Red Hat Single Sign-On は、LDAP サーバーからではなく、データベースから特定のユーザー属性を読み取るようにマッパーを設定します。ただし、後で編集モードを変更すると、設定が UNSYNCED モードで変更されたかどうかを検出できないため、マッパーの設定は変更できません。LDAP プロバイダーの作成時に Edit Mode を決定します。この注記は、ユーザーのインポート スイッチにも適用されます。

4.3.4. その他の設定オプション

コンソール表示名
管理コンソールで表示するプロバイダーの名前。
Priority
ユーザーを検索したり、ユーザーを追加したりする際のプロバイダーの優先順位です。
登録の同期
Red Hat Single Sign-On で作成した新規ユーザーを LDAP に追加する場合は、この切り替えを ON に切り替えます。
Kerberos 認証を許可
LDAP からプロビジョニングされたユーザーデータを使用して、レルムで Kerberos/SPNEGO 認証を有効にします。詳細は「Kerberos」セクションを参照してください。
その他のオプション
マウスポインターを管理コンソールのツールチップの上に置き、これらのオプションの詳細を表示します。

4.3.5. SSL 経由での LDAP への接続

LDAP ストアにセキュアな接続 URL (例: ldaps://myhost.com:636) を設定する場合、Red Hat Single Sign-On は SSL を使用して LDAP サーバーと通信します。Red Hat Single Sign-On が LDAP への SSL 接続を信頼できるように、Red Hat Single Sign-On サーバー側でトラストストアを設定します。

Truststore SPI を使用して Red Hat Single Sign-On のグローバルトラストストアを設定します。グローバルトラストストアの設定の詳細については、サーバーのインストールおよび設定ガイドを参照してください。Truststore SPI を設定しないと、トラストストアは Java によって提供されるデフォルトのメカニズムにフォールバックします。これは、システムプロパティーが設定されていないと、javax.net.ssl. ONLY システムプロパティーまたは JDK からの cacerts ファイルによって提供されるファイルになります。

LDAP フェデレーションプロバイダー設定の Use Truststore SPI 設定プロパティーは、トラストストア SPI を制御します。デフォルトでは、Red Hat Single Sign-On はプロパティーを Only for ldaps に設定します。これは、ほとんどのデプロイメントでで十分です。LDAP への接続 URL が ldaps のみで始まる場合は、Red Hat Single Sign-On では Truststore SPI を使用します。

4.3.6. LDAP ユーザーの Red Hat Single Sign-On への同期

Import Users オプションを設定すると、LDAP プロバイダーは LDAP ユーザーの Red Hat Single Sign-On ローカルデータベースへのインポートを処理します。ユーザーの初回ログイン時に、LDAP プロバイダーは LDAP ユーザーを Red Hat Single Sign-On データベースにインポートし、LDAP パスワードを検証します。この場合、Red Hat Single Sign-On がユーザーをインポートする場合のみ、ログインが初めてログインされます。管理コンソールの Users メニューをクリックし、View all users ボタンをクリックすると、少なくとも Red Hat Single Sign-On によって少なくとも 1 度認証された LDAP ユーザーのみが表示されます。Red Hat Single Sign-On はこの方法でユーザーをインポートするため、この操作は LDAP ユーザーデータベース全体のインポートをトリガーしません。

全 LDAP ユーザーを Red Hat Single Sign-On データベースに同期する場合は、LDAP プロバイダー設定ページで Sync Settings を設定し、有効にすることができます。

2 種類の同期が存在します。

定期的な完全同期 (Periodic Full)
このタイプは、すべての LDAP ユーザーを Red Hat Single Sign-On データベースに同期します。LDAP ユーザーはすでに Red Hat Single Sign-On にありますが、LDAP で利用でき、Red Hat Single Sign-On データベースで直接更新されます。
定期的な変更したユーザー同期 (Periodic Changed)
同期時に、Red Hat Single Sign-On は、最後の同期のみ後に作成または更新されたユーザーを作成または更新します。

同期する最適な方法として、LDAP プロバイダーの初回作成時にすべてのユーザーの同期をクリックし、変更したユーザーの定期的な同期を設定するのが最適です。

4.3.7. LDAP マッパー

LDAP マッパーは LDAP プロバイダーによってトリガーされる listeners です。別の拡張は LDAP 統合を指定します。LDAP マッパーは、以下の場合にトリガーされます。

  • ユーザーは LDAP を使用してログインします。
  • ユーザーは最初に登録されます。
  • 管理コンソールはユーザーにクエリーを実行します。

LDAP フェデレーションプロバイダーを作成すると、Red Hat Single Sign-On はこのプロバイダーの mappers のセットを自動的に提供します。これは、ユーザーは既存のマッパーを開発したり、既存のマッパーを更新/削除したりすることができます。

ユーザー属性マッパー
このマッパーは、Red Hat Single Sign-On ユーザーの属性にマップする LDAP 属性を指定します。たとえば、mail LDAP 属性を Red Hat Single Sign-On データベースの email 属性に設定できます。このマッパーの実装では、1 対 1 のマッピングが常に存在します。
fullName Mapper
このマッパーはユーザーのフルネームを指定します。Red Hat Single Sign-On は LDAP 属性 (通常は cn) に名前を保存し、Red Hat Single Sign-On データベースの firstName および lastname 属性にマッピングします。ユーザーのフルネームを含む cn は LDAP デプロイメントで共通です。
注記

Red Hat Single Sign-On で新規ユーザーを登録し、Sync Registrations が LDAP プロバイダー用に ON になっている場合、fullName マッパーはユーザー名にフォールバックできます。このフォールバックは、Microsoft Active Directory (MSAD) を使用する際に役に立ちます。MSAD の一般的なセットアップでは、cn LDAP 属性を fullName として設定し、同時に LDAP プロバイダー設定の RDN LDAP Attribute として cn LDAP 属性を使用します。この設定では、Red Hat Single Sign-On はユーザー名にフォールバックします。たとえば、Red Hat Single Sign-On ユーザー「john123」を作成して firstName と lastName を空のままにすると、フルネームは LDAP の cn の値として「john123」を保存します。firstName および lastName に "John Doe" を入力すると、完全な名前マッパーは LDAP cn を "John Doe" の値に更新し、ユーザー名へのフォールバックが必要ありません。

ハードコードされた属性マッパー
このマッパーは LDAP と一緒にリンクされた各 Red Hat Single Sign-On ユーザーにハードコードされた属性値を追加します。また、このマッパーは enabled または emailVerified ユーザー プロパティーの値を強制的に実行することもできます。
ロールマッパー
このマッパーは、LDAP から Red Hat Single Sign-On ロールマッピングへのロールマッピングを設定します。単一のロールマッパーは LDAP ロール (通常は LDAP ツリーの特定ブランチからのグループ) を、指定されたクライアントのレルムロールまたはクライアントロールに対応するロールにマップできます。同じ LDAP プロバイダーに追加のロールマッパーを設定できます。たとえば、ou=main,dc=example,dc=org 下のグループからのロールマッピングをレルムロールマッピングにマッピングし、ou=finance,dc=example,dc=org 下のグループから、クライアント finance のクライアントロールマッピングへマップするように指定できます。
ハードコーディングされたロールマッパー
このマッパーは、指定された Red Hat Single Sign-On ロールを LDAP プロバイダーから各 Red Hat Single Sign-On ユーザーに付与します。
Group Mapper
このマッパーは、LDAP ツリーのブランチから、Red Hat Single Sign-On 内のグループに LDAP グループをマッピングします。また、Red Hat Single Sign-On の LDAP からユーザーグループマッピングに、ユーザーグループマッピングも伝播されます。
MSAD ユーザーアカウントマッパー
このマッパーは、Microsoft Active Directory (MSAD) に固有のものです。MSAD ユーザーアカウントの状態を、有効なアカウントまたは期限切れのパスワードなどの Red Hat Single Sign-On アカウントの状態に統合することができます。このマッパーは userAccountControl および pwdLastSet LDAP 属性を使用します。これは MSAD に固有で、LDAP 標準ではありません。たとえば、pwdLastSet の値が 0 の場合、Red Hat Single Sign-On ユーザーはパスワードを更新する必要があります。結果として、UPDATE_PASSWORD の必要なアクションがユーザーに追加されます。userAccountControl の値が 514 (無効) の場合、Red Hat Single Sign-On ユーザーが無効になります。
Certificate Mapper
このマッパーは X.509 証明書をマッピングします。Red Hat Single Sign-On は、それを X.509 認証と、Full certificate in PEM format を ID ソースとして使用します。このマッパーは User Attribute Mapper と同様に動作しますが、Red Hat Single Sign-On は PEM または DER フォーマットの証明書を保存する LDAP 属性に対してフィルタリングできます。このマッパーを使用して、Always Read Value From LDAP を有効にします。

username、firstname、lastname、email などの基本的な Red Hat Single Sign-On ユーザー属性を対応する LDAP 属性にマップするユーザー属性マッパー。これらを拡張し、独自の追加属性マッピングを提供できます。管理コンソールは、対応するマッパーの設定に役立つツールチップを提供します。

4.3.8. パスワードのハッシュ

Red Hat Single Sign-On がパスワードを更新すると、Red Hat Single Sign-On はパスワードをプレーンテキスト形式で送信します。このアクションは、ビルトインの Red Hat Single Sign-On データベースのパスワードを更新することとは異なります。Red Hat Single Sign-On ハッシュと、データベースに送信する前にパスワードをソルトします。LDAP の場合、Red Hat Single Sign-On は LDAP サーバーに依存してパスワードをハッシュ化し、ソルトします。

デフォルトでは、MSAD、RHDS、FreeIPA ハッシュ、ソルトパスワードなどの LDAP サーバー。RFC3062 で説明されているように LDAPv3 Password Modify Extended Operation を使用しない限り、OpenLDAP や ApacheDS などのその他の LDAP サーバーは、パスワードをプレーンテキストに保存します。LDAP 設定ページで LDAPv3 Password Modify Extended Operation を有効にします。詳細は、お使いの LDAP サーバーのドキュメントを参照してください。

警告

ldapsearch を使用して変更したディレクトリーエントリーを検査することで、ユーザーパスワードが正しくハッシュ化され、プレーンテキストとして保存されていることと、base64 が userPassword 属性値をデコードしていることを常に確認します。

4.3.9. トラブルシューティング

カテゴリー org.keycloak.storage.ldap では、ログレベルを TRACE に増やすと便利です。この設定により、多数のロギングメッセージは TRACE レベルの server.log ファイルに送信されます。これには、すべてのクエリーのログが LDAP サーバーとクエリーの送信に使用されたパラメーターが含まれます。ユーザーフォーラムまたは JIRA で LDAP の質問を作成する場合は、TRACE ロギングを有効にしてサーバーログを添付することを検討してください。大きすぎる場合は、操作中にログに追加されたメッセージを含む、サーバーログのスニペットだけを含めるのが良いでしょう。これにより、問題が発生します。

  • LDAP プロバイダーを作成すると、以下から始まる INFO レベルのサーバーログにメッセージが表示されます。

    When you create LDAP provider, message appear in the server log in the INFO level starting with:
Creating new LDAP Store for the LDAP storage provider: ...

LDAP プロバイダーの設定が表示されます。質問またはバグを報告する前に、このメッセージを LDAP 設定に含めることが推奨されます。最終的には、一部の設定変更 (含めない) をプレースホルダーの値に置き換えることもあると考えられます。1 つ目は bindDn=some-placeholder です。connectionUrl の場合は、自由に置き換えるようにしてください。ただし、一般的には、使用されたプロトコル (ldap vs ldaps) を含めると便利です。同様に、LDAP マッパーの設定の詳細を含めると役に立ちます。これは、DEBUG レベルで以下のようなメッセージと共に表示されます。

Mapper for provider: XXX, Mapper name: YYY, Provider: ZZZ ...

これらのメッセージは、有効になっている DEBUG ロギングとともに表示されることに注意してください。

  • パフォーマンスまたは接続プールの問題を追跡するには、プロパティー Connection Pool Debug Level の値を設定することを検討してください。

パフォーマンスまたは接続プールの問題を追跡するには、LDAP プロバイダーのプロパティー Connection Pool Debug Level の値を all の値に設定することを検討してください。これにより、LDAP 接続プールのロギングが含まれるサーバーログに多くの追加メッセージがサーバーログに追加されます。これは、接続プールまたはパフォーマンスに関連する問題を追跡するために使用できます。

注記

接続プールの設定を変更した後に、Keycloak サーバーを再起動して LDAP プロバイダー接続の再初期化を適用する必要がある場合があります。

サーバーの再起動後に接続プールのメッセージがこれ以上表示されない場合は、接続プールが LDAP サーバーでは機能しないことを示すことができます。

  • LDAP の問題を報告する場合、ターゲットデータとともに LDAP ツリーの一部を添付すると、環境で問題が発生します。たとえば、一部のユーザーログインに多くの時間がかかる場合、さまざまな「グループ」エントリーの member の数を表示する LDAP エントリーをアタッチすることができます。この場合、これらのグループエントリーが Red Hat Single Sign-On の一部のグループ LDAP マッパー (またはロール LDAP マッパー) にマップされるかどうかを追加するのに役立ちます。

LDAP の問題を報告する場合、ターゲットデータとともに LDAP ツリーの一部を添付すると、環境で問題が発生します。たとえば、一部のユーザーログインに多くの時間がかかる場合、さまざまな「グループ」エントリーの member の数を表示する LDAP エントリーをアタッチすることができます。この場合、これらのグループエントリーが Red Hat Single Sign-On の一部のグループ LDAP マッパー (またはロール LDAP マッパー) にマップされるかどうかを追加するのに役立ちます。

4.4. SSSD および FreeIPA Identity Management の統合

Red Hat Single Sign-On には、SSSD (System Security Services Daemon) プラグインが含まれます。SSSD は Fedora および Red Hat Enterprise Linux (RHEL) に含まれており、複数の ID プロバイダーおよび認証プロバイダーへのアクセスを提供します。SSSD は、フェイルオーバーやオフラインサポートなどの利点も提供します。詳細は、Red Hat Enterprise Linux Identity Management のドキュメントを参照してください。

SSSD は、認証とアクセス制御を提供する FreeIPA アイデンティティー管理 (IdM) サーバーとも統合します。この統合により、Red Hat Single Sign-On は特権のあるアクセス管理 (PAM) サービスに対して認証し、SSSD からユーザーデータを取得できます。Linux 環境における Red Hat Identity Management の使用に関する詳細は、Red Hat Enterprise Linux Identity Management のドキュメント を参照してください。

keycloak sssd freeipa integration overview

Red Hat Single Sign-On および SSSD は、読み取り専用の D-Bus インターフェースを介して通信します。このため、ユーザーのプロビジョニングおよび更新方法は、FreeIPA/IdM 管理インターフェースを使用する方法です。デフォルトでは、インターフェースはユーザー名、メール、名、および姓をインポートします。

注記

Red Hat Single Sign-On は、グループおよびロールを自動的に登録しますが、同期しません。Red Hat Single Sign-On の Red Hat Single Sign-On 管理者による変更は SSSD と同期しません。

4.4.1. freeipa/IdM サーバー

FreeIPA Docker イメージは、Docker Hub で入手できます。FreeIPA サーバーを設定するには、FreeIPA のドキュメントを参照してください。

手順

  1. 以下のコマンドを使用して FreeIPA サーバーを実行します。

     docker run --name freeipa-server-container -it \
     -h server.freeipa.local -e PASSWORD=YOUR_PASSWORD \
     -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
     -v /var/lib/ipa-data:/data:Z freeipa/freeipa-server

    server.freeipa.local のパラメーター -h は FreeIPA/IdM サーバーのホスト名を表します。YOUR_PASSWORD を独自のパスワードに変更します。

  2. コンテナーが起動したら、/etc/hosts ファイルを以下のように変更します。

    x.x.x.x     server.freeipa.local

    この変更を加えない場合は、DNS サーバーを設定する必要があります。

  3. 以下のコマンドを使用して、SSSD フェデレーションプロバイダーが Red Hat Single Sign-On で開始および実行されるように、IPA ドメインに Linux サーバーを登録します。

     ipa-client-install --mkhomedir -p admin -w password
  4. クライアントで以下のコマンドを実行して、インストールが機能していることを確認します。

     kinit admin
  5. パスワードを入力します。
  6. 以下のコマンドを使用して IPA サーバーにユーザーを追加します。

    $ ipa user-add <username> --first=<first name> --last=<surname> --email=<email address> --phone=<telephoneNumber> --street=<street> \      --city=<city> --state=<state> --postalcode=<postal code> --password
  7. kinit を使用してユーザーのパスワードを強制的に設定します。

     kinit <username>
  8. 以下のコマンドを入力して通常の IPA 操作を復元します。

    kdestroy -A
    kinit admin

4.4.2. SSSD および D-Bus

フェデレーションプロバイダーは、D-BUS を使用して SSSD からデータを取得します。PAM を使用してデータを認証します。

手順

  1. sssd-dbus RPM をインストールします。

    $ sudo yum install sssd-dbus
  2. 以下のプロビジョニングスクリプトを実行します。

    $ bin/federation-sssd-setup.sh

    このスクリプトは、/etc/sssd/sssd.conf に以下の変更を加えます。

      [domain/your-hostname.local]
      ...
      ldap_user_extra_attrs = mail:mail, sn:sn, givenname:givenname, telephoneNumber:telephoneNumber
      ...
      [sssd]
      services = nss, sudo, pam, ssh, ifp
      ...
      [ifp]
      allowed_uids = root, yourOSUsername
      user_attributes = +mail, +telephoneNumber, +givenname, +sn
  3. dbus-send を実行して、設定が正常に行われていることを確認します。

    sudo dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups string:john

    設定に成功すると、ユーザーのグループが表示されます。このコマンドによってタイムアウトまたはエラーが返されると、Red Hat Single Sign-On で実行されているフェデレーションプロバイダーはデータを取得できません。このエラーは、通常、サーバーが FreeIPA IdM サーバーに登録されていないか、SSSD サービスにアクセスするパーミッションがないために発生します。

    SSSD サービスにアクセスするパーミッションがない場合は、Red Hat Single Sign-On サーバーを実行しているユーザーが、以下のセクションの /etc/sssd/sssd.conf ファイルにあることを確認します。

    [ifp]
    allowed_uids = root, your_username

4.4.3. SSSD フェデレーションプロバイダーの有効化

Red Hat Single Sign-On は、D-Bus との低レベルの通信に DBus-Java を使用します。D-Bus は、Unix ソケットライブラリー によって異なります。

SSSD フェデレーションプロバイダーを有効にする前に、このライブラリーの RPM をインストールします。

$ sudo yum install rh-sso7-libunix-dbus-java

Red Hat Single Sign-On は JNA を使用して PAM で認証します。JAN パッケージがインストールされていることを確認します。

$ sudo yum install jna

sssctl user-checks コマンドを使用して設定を検証します。

  $ sudo sssctl user-checks admin -s keycloak

4.5. フェデレーションされた SSSD ストアの設定

インストール後に、フェデレーションされた SSSD ストアを設定します。

手順

  1. メニューの User Federation をクリックします。
  2. Add Provider 一覧から sssd を選択します。Red Hat Single Sign-On では、sssd 設定ページに移動します。
  3. Save をクリックします。

FreeIPA/IdM 認証情報を使用して Red Hat Single Sign-On に対して認証できるようになりました。

4.6. カスタムプロバイダー

Red Hat Single Sign-On には、カスタムプロバイダーを開発するための User Storage Federation の Service Provider Interface (SPI) があります。カスタマープロバイダーの開発に関するドキュメントは、Server Developer Guide を参照してください。

第5章 ユーザーの管理

管理コンソールから、ユーザーの管理に使用できる幅広いアクションがあります。

5.1. ユーザーの作成

ユーザーが必要とするアプリケーションを持つレルムにユーザーを作成します。他のレルムの作成を目的としたマスターレルムでユーザーを作成しないでください。

前提条件

  • マスターレルム以外のレルムを使用している。

手順

  1. メニューの Users をクリックします。
  2. Add User をクリックします。
  3. 新規ユーザーの詳細を入力します。

    注記

    Username は、唯一の必須フィールドです。

  4. Save をクリックします。詳細を保存すると、新規ユーザーの Management ページが表示されます。

5.2. ユーザーの認証情報の定義

Credentials タブでユーザーの認証情報を管理できます。

認証情報管理

user credentials

このタブには以下のフィールドが含まれます。

Position
位置 コラムの矢印ボタンを使用すると、ユーザーの認証情報の優先度をシフトできます。最上部にある認証情報が最も優先されます。優先順位は、ユーザーのログイン後に最初に表示される認証情報を決定します。
タイプ
この列には、パスワードOTP などの認証情報のタイプが表示されます。
User Label
これは、ログイン時に選択オプションとして示される際に認証情報を認識するための割り当て可能なラベルです。認証情報を記述するために任意の値に設定できます。
データ
これは、認証情報に関する機密ではない技術情報です。これは、デフォルトでは非表示になっています。Show data…​ をクリックすると、認証情報のデータを表示できます。
アクション
このコラムには 2 つのアクションがあります。Save をクリックして値またはユーザーフィールドを記録します。Delete をクリックして認証情報を削除します。

管理コンソールの特定のユーザーに他の種類の認証情報は設定できません。このタスクはユーザーの責任者です。

ユーザーが OTP デバイスを失った場合や、認証情報に不正アクセスが発生した場合は、ユーザーの認証情報を削除できます。Credentials タブでユーザーの認証情報のみを削除できます。

5.2.1. ユーザーのパスワードの設定

ユーザーにパスワードがない場合や、パスワードが削除された場合、パスワード の設定 セクション が表示されます。

ユーザーのパスワードがすでにある場合は、Reset Password セクションでリセットできます。

手順

  1. メニューの Users をクリックします。Users ページが表示されます。
  2. ユーザーを選択します。
  3. Credentials タブをクリックします。
  4. パスワードの設定 セクションに新しいパスワードを入力します。
  5. パスワードの設定 をクリックします。

    注記

    TemporaryON の場合は、初回ログイン時にパスワードを変更する必要があります。ユーザーが指定したパスワードを維持できるようにするには、TemporaryOFF に設定します。ユーザーは、Set Password をクリックしてパスワードを変更する必要があります。

  6. または、ユーザーにパスワードをリセットを要求するメールを送信することもできます。

    1. 認証情報リセット の下にある アクションのリセット 一覧に移動します。
    2. 一覧から パスワードの更新 を選択します。
    3. Send Email をクリックします。送信されたメールには、ユーザーを Update Password ウィンドウに転送するリンクが含まれます。
    4. オプションで、メールリンクの有効性を設定できます。これは、Realm SettingsTokens タブでデフォルトの事前設定に設定されます。

5.2.2. OTP の作成

OTP がレルムの条件である場合、ユーザーは Red Hat Single Sign-On Account Console に移動し、新しい OTP ジェネレーターを再設定する必要があります。OTP が必要な場合は、ログイン時に新しい OTP ジェネレーターを再設定する必要があります。

この代わりに、ユーザーが OTP ジェネレーターをリセットするユーザーへメールを送信することもできます。以下の手順では、ユーザーが OTP 認証情報をすでに持っているかどうかも適用されます。

前提条件

  • 適切なレルムにログインしている。

手順

  1. メインメニューで Users をクリックします。Users ページが表示されます。
  2. ユーザーを選択します。
  3. Credentials タブをクリックします。
  4. Reset Actions 一覧に移動します。
  5. Configure OTP をクリックします。
  6. Send Email をクリックします。送信されたメールには、OTP 設定ページに転送するリンクが含まれます。

5.3. ユーザー属性の設定

ユーザー属性は、各ユーザーのカスタマイズされたエクスペリエンスを提供します。コンソールでユーザー属性を設定して、各ユーザーに個人的なアイデンティティーを作成できます。

ユーザー

user attributes

前提条件

  • ユーザーが存在するレルムにある。

手順

  1. メニューの Users をクリックします。
  2. 管理するユーザーを選択します。
  3. Attributes タブをクリックします。
  4. キー フィールドに属性名を入力します。
  5. フィールド属性値を入力します。
  6. Add をクリックします。
  7. Save をクリックします。
注記

一部の読み取り専用属性は管理者が更新されることは想定されていません。これには、LDAP プロバイダーによって自動的に入力される LDAP_ID のように設計によって読み取り専用の属性が含まれます。セキュリティー上の理由から、ユーザー管理者が他の属性を読み取り専用にする必要があります。セキュリティー脅威の章の詳細を参照してください。

5.4. ユーザーの自己登録の許可

サードパーティーの承認サーバーとして Red Hat Single Sign-On を使用して、自己登録のユーザーを含むアプリケーションユーザーを管理できます。自己登録を有効にすると、ログインページに登録リンクが表示され、ユーザーがアカウントを作成できるようにします。

登録リンク

registration link

登録を完了するには、ユーザーは登録フォームにプロファイル情報を追加する必要があります。登録フォームは、ユーザーが完了する必要のあるフィールドを削除または追加することでカスタマイズできます。

関連情報

5.4.1. ユーザー登録の有効化

ユーザーが自己登録できるようにします。

手順

  1. メインメニューで Realm Settings をクリックします。
  2. Login タブをクリックします。
  3. ユーザー登録を ON に切り替えます。
  4. Save をクリックします。

この設定を有効にすると、管理コンソールのログインページに 登録 リンクが表示されます。

5.4.2. 新規ユーザーとしての登録

新しいユーザーとして、初回ログインするには、登録フォームを完了する必要があります。プロファイル情報と、登録するパスワードを追加します。

登録フォーム

registration form

前提条件

  • ユーザー登録が有効になっています。

手順

  1. ログインページの 登録 リンクをクリックします。登録ページが表示されます。
  2. ユーザープロファイル情報を入力します。
  3. 新しいパスワードを入力します。
  4. Save をクリックします。

5.5. ログイン時に必要なアクションの定義

ユーザーが初回ログイン時に実行する必要のあるアクションを設定できます。これらのアクションは、ユーザーが認証情報を提供する後に必要になります。最初のログイン後、これらのアクションは不要になりました。必要なアクションを、そのユーザーの Details タブに追加します。

以下は、必要なアクションタイプの例です。

パスワードの更新
ユーザーはパスワードを変更する必要があります。
OTP の設定
これを設定すると、Free OTP または Google Authenticator アプリケーションのいずれかを使用して、モバイルデバイスにワンタイムパスワードジェネレーターを設定する必要があります。
メールの確認
ユーザーは、メールアカウントを検証する必要があります。電子メールは、クリックする必要のある検証リンクを持つユーザーに送信されます。このワークフローが正常に完了したら、ユーザーはログインできるようになります。
プロファイルの更新
ユーザーは、名前、アドレス、電子メール、電話番号などのプロファイル情報を更新する必要があります。

5.5.1. 1 人のユーザーに必要なアクションの設定

任意のユーザーに必要なアクションを設定できます。

手順

  1. メニューの Users をクリックします。
  2. 一覧からユーザーを選択します。
  3. Required User Actions 一覧に移動します。

    user required action

  4. アカウントに追加するすべてのアクションを選択します。
  5. アクション名の横にある X をクリックして削除します。
  6. 追加するアクションを選択したら、Save をクリックします。

5.5.2. すべてのユーザーに必要なアクションの設定

すべての新規ユーザーの最初のログイン前に必要なアクションを指定できます。要件は、Users ページの Add User ボタンまたはログインページの Register リンクが作成したユーザーに適用されます。

手順

  1. メニューで Authentication をクリックします。
  2. Required Actions タブをクリックします。
  3. 必要な 1 つまたは複数の アクションについて、Default Action 列にあるチェックボックスをクリックします。新規ユーザーが初めてログインしたら、選択したアクションを実行する必要があります。

5.5.3. 必要なアクションとしての条件と条件の有効化

Red Hat Single Sign-On に初めてログインする前に、新規ユーザーが契約条件に同意する必要のあるアクションを有効にできます。

手順

  1. メニューで Authentication をクリックします。
  2. Required Actions タブをクリックします。
  3. 利用規約 のアクションを有効にします。
  4. ベースログインテーマの terms.ftl ファイルを編集します。

関連情報

5.6. ユーザーの検索

ユーザーを検索すると、ユーザーのグループやロールなどのユーザーに関する詳細情報が表示されます。

前提条件

  • ユーザーが存在するレルムにある。

手順

  1. メインメニューで Users をクリックします。この Users ページが表示されます。
  2. 検索ボックスに、検索するユーザーのフルネーム、姓名、またはメールアドレスを入力します。検索は、条件に一致するすべてのユーザーを返します。
  3. または、View all users をクリックして、システム内の全ユーザーを一覧表示できます。

    注記

    このアクションでは、LDAP などのフェデレーションされたデータベースではなく、ローカルの Red Hat Single Sign-On データベースのみを検索します。フェデレーションされたデータベースのバックエンドには、ユーザーの検索を可能にするページネーションメカニズムがありません。

    1. フェデレーションされたバックエンドからユーザーを検索するには、ユーザーリストは Red Hat Single Sign-On データベースに同期する必要があります。バックエンドユーザーを Red Hat Single Sign-On データベースに同期するために、検索条件を調整します。
    2. または、左側のメニューで User Federation をクリックします。

      1. 選択したユーザーに変更を適用するには、フェデレーションプロバイダーのあるページの Sync changed users をクリックします。
      2. データベースのすべてのユーザーに変更を適用するには、フェデレーションプロバイダーのあるページの すべてのユーザーの同期 をクリックします。

関連情報

5.7. ユーザーの削除

アプリケーションへのアクセスが必要なくなったユーザーを削除できます。ユーザーが削除されると、ユーザープロファイルとデータも削除されます。

手順

  1. メニューの Users をクリックします。Users ページが表示されます。
  2. View all users をクリックして、削除するユーザーを検索します。

    注記

    または、検索バーを使用してユーザーを検索することもできます。

  3. 削除するユーザーの横にある Delete をクリックし、削除を確定します。

5.8. ユーザーによるアカウントの削除の有効化

管理コンソールでこの機能を有効にすると、エンドユーザーおよびアプリケーションは、アカウントコンソールでアカウントを削除できます。この機能を有効にすると、その機能を特定のユーザーに提供できます。

5.8.1. アカウントの削除機能の有効化

この機能により、必要なアクションタブでこの機能を有効にします。

手順

  1. メニューで Authentication をクリックします。
  2. Required Actions タブをクリックします。
  3. Delete Account 行で Enabled を選択します。

    必要なアクションタブでアカウントを削除します。

    enable delete account action

5.8.2. ユーザーに delete-account ロールの指定

アカウントの削除を許可するロールを特定のユーザーに付与できます。

手順

  1. メニューの Users をクリックします。
  2. ユーザーを選択します。
  3. Role Mappings タブをクリックします。
  4. Client Roles リストから account を選択します。
  5. Available Rolesdelete-account を選択します。
  6. Add selected をクリックします。

    delete-account ロール

    delete-account role

5.8.3. アカウントの削除

delete-account ロールを取得したら、独自のアカウントを削除できます。

  1. アカウントコンソールにログインします。
  2. Personal Info ページの下部に、Delete Account をクリックします。

    アカウントページの削除

    delete account page

  3. 認証情報を入力し、削除を確定します。

    確認削除

    delete account confirm

    注記

    このアクションは元に戻せません。Red Hat Single Sign-On のすべてのデータが削除されます。

5.9. ユーザーの権限借用

適切なパーミッションを持つ管理者はユーザーの権限を借用できます。たとえば、アプリケーションでバグが発生した場合、管理者はユーザーの権限を借用して問題を調査または複製できます。

レルムの impersonation ロールを持つユーザーは、ユーザーの権限を借用できます。

user details

  • 管理者とユーザーが同じレルムにある場合、管理者はログアウトされ、切り替えているユーザーとして自動的にログインします。
  • 管理者およびユーザーが異なるレルムにある場合、管理者はログインし、そのユーザーのレルムでユーザーとしてログインします。

両方のインスタンスで、切り替えられたユーザーの User Account Management ページが表示されます。

Users ページの Details タブから Impersonate ボタンにアクセスできます。

関連情報

5.10. reCAPTCHA の有効化

ボットから登録を保護するために、Red Hat Single Sign-On は Google reCAPTCHA と統合しています。

reCAPTCHA を有効にしたら、ログインテーマの register.ftl を編集して、登録ページで reCAPTCHA ボタンの配置と停止を設定できます。

手順

  1. 以下の URL をブラウザーに入力します。

    https://developers.google.com/recaptcha/
  2. reCAPTCHA サイトキーおよびシークレットを取得するために API キーを作成します。本手順で後で使用できるように、reCAPTCHA サイトキーおよび秘密を書き留めておきます。

    注記

    localhost はデフォルトで動作します。ドメインを指定する必要はありません。

  3. Red Hat Single Sign-On 管理コンソールに移動します。
  4. メニューで Authentication をクリックします。
  5. Flows タブをクリックします。
  6. ドロップダウンメニューから 登録 を選択します。
  7. reCAPTCHA の要件を Required に設定します。これにより、reCAPTCHA が有効になります。
  8. reCAPTCHA フローエントリーの右側にある Actions をクリックします。
  9. Config リンクをクリックします。

    reCAPTCHA 設定ページ

    recaptcha config

    1. Google reCAPTCHA の Web サイトから生成された Recaptcha Site Key を入力します。
    2. Google reCAPTCHA の Web サイトから生成された Recaptcha Secret を入力します。
  10. 登録ページを iframe として使用するよう Google を承認します。

    注記

    Red Hat Single Sign-On の Web サイトには、iframe にログインページダイアログを含めることができません。この制限は、クリック攻撃を防ぐことです。Red Hat Single Sign-On で設定されるデフォルトの HTTP 応答ヘッダーを変更する必要があります。

    1. メニューで Realm Settings をクリックします。
    2. Security Defenses タブをクリックします。
    3. X-Frame-Options ヘッダーのフィールドに https://www.google.com を入力します。
    4. Content-Security-Policy ヘッダーのフィールドに https://www.google.com を入力します。

関連情報

5.11. ユーザープロファイルの定義

Red Hat Single Sign-On では、ユーザーは属性セットに関連付けられます。これらの属性は、Red Hat Single Sign-On 内でユーザーの説明や識別のために使用され、これらに関する追加情報をアプリケーションに渡すのに使用されます。

ユーザープロファイルは、ユーザー属性とレルム内で管理する方法を表す明確に定義されたスキーマを定義します。ユーザー情報に対する一貫したビューを提供することで、管理者は属性の管理方法に関するさまざまな要素を制御したり、Red Hat Single Sign-On を拡張して追加の属性をサポートするのがより簡単になります。

他の機能の中で、管理者は以下を行うことができます。

  • ユーザー属性のスキーマを定義
  • コンテキスト情報に基づいて属性が必要なかどうかを定義します (例: ユーザーまたは管理者に必要となる場合、または両方の場合、または要求されるスコープに応じて)。
  • ユーザー属性を表示および編集するための特定のパーミッションを定義してください。これにより、一部の属性が表示できないか、または 3 番目の部分 (管理者を含む) によって変更されない、強力なプライバシー要件に準拠することができます。
  • ユーザープロファイルのコンプライアンスを動的に実施して、ユーザー情報が常に、属性に関連付けられたメタデータとルールに準拠します。
  • 組み込みバリデーターを利用するか、カスタムレジストリーを書き込むことで、属性ごとに検証ルールを定義します。
  • 属性の定義やそれらを手動で変更しなくても、ユーザーがアカウントコンソール内の登録、更新プロファイル、ブローカー、個人情報などと対話するフォームを動的にレンダリングします。

ユーザープロファイルの機能は、ユーザープロファイル SPI によってサポートされます。デフォルトでは、これらの機能は無効になり、レルムは、レガシー動作と後方互換性を維持するデフォルト設定を使用するよう設定されます。

注記

レガシーの動作は、カスタム属性の管理方法に制限なく、ユーザー名、メール、最初、および姓などのユーザールート属性を管理する際に、Red Hat Single Sign-On が使用するデフォルトの制約を維持することです。登録、プロファイル更新、ブローカー、およびアカウントコンソールを介したアカウントフローなどのユーザーフローについては、ユーザーが上記の属性を変更できるように、上記の属性を使用するように制限されています。

Red Hat Single Sign-On をすでに使用している場合は、レガシー動作がこれまでに使用している内容になります。

宣言的プロバイダーは、レガシーの動作とは異なるため、管理コンソールと明確に定義された JSON スキーマを使用して、レルムにユーザープロファイル設定を定義する柔軟性が非常に高くなります。

次のセクションでは、宣言型プロバイダーを使用して独自のユーザープロファイル設定を定義する方法を説明します。

注記

今後は、Red Hat Single Sign-On ではレガシー動作のサポートがなくなりました。理想的には、ユーザープロファイルが提供する新機能を確認し、それに応じてレルムを移行する必要があります。

5.11.1. ユーザープロファイルの有効化

注記

宣言型ユーザープロファイルは テクノロジープレビュー であるため、完全にサポートされていません。この機能はデフォルトで無効にされています。

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

declarative_user_profile 機能を有効にする他に、レルムのユーザープロファイルを有効にする必要があります。これには、左側のメニューの Realm Settings リンクをクリックし、User Profile Enabled スイッチを有効にします。

user profile enabling

有効化して Save ボタンをクリックすると、ユーザー属性の設定を管理できる User Profile にアクセスできます。

レルムのユーザープロファイルを有効にすると、Red Hat Single Sign-On は、ユーザープロファイル設定に基づいて属性の管理方法に追加の制約を指定します。つまり、以下は、この機能が有効な場合に予想される内容の一覧です。

  • 管理の観点からは、ユーザー詳細ページの Attributes タブに、ユーザープロファイル設定で定義された属性のみが表示されます。属性管理時には、属性ごとに定義された条件も考慮されます。
  • アカウントコンソールにおける登録、更新プロファイル、ブローカー、個人情報などのユーザー向けフォームは、ユーザープロファイルの設定に基づいて動的にレンダリングされます。そのため、Red Hat Single Sign-On は異なるテンプレートに依存して、これらのフォームを動的にレンダリングします。

次のトピックでは、ユーザープロファイル設定を管理する方法と、レルムへの影響を説明します。

5.11.2. ユーザープロファイルの管理

ユーザープロファイル設定は、レルムごとに管理されます。これには、左側のメニューで Realm Settings リンクをクリックし、User Profile タブをクリックします。

ユーザープロファイルタブ

user profile tab

Attributes サブタブでは、現在ユーザープロファイルに関連付けられている属性の一覧があります。デフォルトでは、設定はユーザー root 属性に基づいて作成され、各属性は検証およびパーミッションに関してデフォルトで設定されます。

Attribute Groups サブタブで、属性グループを管理できます。属性グループを使用すると、ユーザーに表示されるフォームをレンダリングする際に属性を関連付けることができます。

注記

現在、属性グループはレンダリング目的でのみ使用されますが、今後はリンク先の属性へのトップレベル設定の定義も有効にする必要があります。

JSON Editor サブタブで、明確に定義された JSON スキーマを使用して設定を表示および編集できます。他のタブで表示される JSON 設定に反映されたときに、変更を加えます。

次のセクションでは、Attributes サブタブで設定を管理する方法を学びます。

5.11.3. 属性の管理

Attributes サブタブで、ユーザープロファイルに関連する属性を作成、編集、および削除できます。

新しい属性を定義してユーザープロファイルに関連付けるには、属性一覧の右上にある Create ボタンをクリックします。

属性設定

user profile create attribute

属性の設定時に、以下の設定を定義できます。

名前
属性の名前。
表示名
属性のユーザーフレンドリーな名前。主にユーザーに表示されるフォームをレンダリングする場合に使用されます。これは国際化をサポートするため、メッセージバンドルから値をロードできるようにします。
属性グループ
属性が属する属性グループ (ある場合)。
スコープを指定した場合に有効化
属性を動的に有効化するためにスコープのリストを定義します。設定されていない場合、属性は常に有効になり、ユーザーに表示されるフォームをレンダリングする際に、ユーザープロファイルの管理時に常にその制約が強制されます。そうしないと、リスト内のスコープのいずれかがクライアントによって要求される場合にのみ、同じ制約が適用されます。
必須
必要に応じて属性を設定します。有効でなければ、属性は任意です。それ以外の場合は、ユーザーおよび管理者が属性を提供する必要があります。また、必須の属性も、クライアントが必要とするスコープをベースにする必要があります。
パーミッション
このセクションでは、ユーザーおよび管理者の読み取りおよび書き込みパーミッションを定義できます。
検証
本セクションでは、属性値を管理する際に実行される検証を定義できます。Red Hat Single Sign-On は、独自の追加の可能性から選択できる組み込みバリデーターのセットを提供します。
Annotation
このセクションでは、アノテーションを属性に関連付けることができます。アノテーションは、レンダリングの目的で追加のメタデータをフロントエンドに渡すのに役立ちます。

5.11.3.1. パーミッションの管理

Permission セクションで、アクセスユーザーおよび管理者が属性の読み書きレベルを定義できます。

属性パーミッション

user profile permission

そのためには、以下の設定を使用できます。

ユーザー表示可能か?
有効にすると、属性を表示できます。それ以外の場合は、ユーザーは属性にアクセスできません。
ユーザーを編集可能か?
有効にすると、ユーザーは属性を表示および編集できます。それ以外の場合は、ユーザーは属性への書き込み権限がありません。
管理者ビューはどれですか?
有効にすると、管理者は属性を表示できます。それ以外の場合は、管理者は属性にアクセスできません。
管理者を編集可能か?
有効にすると、管理者は属性を表示および編集できます。それ以外の場合は、管理者は属性への書き込み権限がありません。
注記

属性を作成すると、属性にパーミッションが設定されません。実質的には、ユーザーまたは管理者にも属性はアクセスできません。属性を作成したら、ターゲット対象者のみが属性を表示できるように、パーミッションを設定します。

パーミッションには、属性の管理方法とユーザーに表示される形式で属性の管理方法に直接影響があります。

たとえば、ユーザーが属性を表示可能とすると、管理コンソールを介してユーザーを管理する場合 (ユーザー API からも)、管理者は属性にアクセスできません。また、プロファイルの更新時には属性を変更できません。ユーザー属性が既存のアイデンティティーストア (フェデレーション) から取得され、ソースアイデンティティーストア以外の属性を更新せずに属性をユーザーに表示される場合に、興味のある設定。

同様に、ユーザーの読み取り専用アクセスを持つ管理者に対してのみ、属性を書き込み可能としてマークすることもできます。この場合、属性の管理は管理者のみが許可されます。

プライバシーの要件によっては、管理者にもアクセスできるが、ユーザーの読み取り/書き込みパーミッションで属性にアクセスすることが望ましい場合があります。

ユーザープロファイル設定に新しい属性を追加する場合は必ず、適切なパーミッションを設定してください。

5.11.3.2. 検証の管理

Validation セクションで、異なる形式の検証から選択し、属性値が特定のルールに準拠することを確認できます。

属性の検証

user profile validation

Red Hat Single Sign-On は、追加設定なしで異なるバリデーターを提供します。

名前Description設定

長さ

最小と最大長に基づいて文字列値の長さを確認します。

Min: 許可される最小の長さを定義する整数。

最大: 許容最大長を定義する整数。

trim-disabled: 検証前に値がトリミングされるかどうかを定義するブール値。

整数

値が整数または下層にあるか、または上位の範囲内であるかどうかを確認します。範囲が定義されていない場合、バリデーターは、値が有効な数字のみを確認します。

Min: 小さい範囲を定義する整数。

max: 上限を定義する整数。

double

値が二重で、下層または上位の範囲内であるかどうかを確認します。範囲が定義されていない場合、バリデーターは、値が有効な数字のみを確認します。

Min: 小さい範囲を定義する整数。

max: 上限を定義する整数。

uri

値が有効な URI かどうかを確認します。

None

pattern

値が特定の RegEx パターンと一致するかどうかを確認します。

パターン: 値の検証時に使用する RegEx パターン。

error-message: i18n バンドルのエラーメッセージのキー。設定されていない場合には、汎用メッセージが使用されます。

email

値が有効なメールアドレスの形式かどうかを確認します。

None

local-date

レルムまたはユーザーロケールに基づいて、値が有効な形式かどうかを確認します。

None

person-name-prohibited-characters

値がスクリプトインジェクションなどの攻撃にもう 1 つのバリアとして有効な人名であるかを確認します。検証は、デフォルト RegEx パターンをベースとしています。このパターンでは、文字が人名では一般的ではありません。

error-message: i18n バンドルのエラーメッセージのキー。設定されていない場合には、汎用メッセージが使用されます。

username-prohibited-characters

値がスクリプトインジェクションなどの攻撃のためにもう 1 つのバリアとして有効なユーザー名であるかを確認します。検証は、ユーザー名に共通の文字をブロックするデフォルトの RegEx パターンに基づいています。

error-message: i18n バンドルのエラーメッセージのキー。設定されていない場合には、汎用メッセージが使用されます。

options

値が許可された値の定義されたセットからのものであるかどうかを確認してください。選択フィールドと複数選択フィールドから入力された値を検証するのに便利です。

options: 許可された値を含む文字列の配列。

5.11.3.2.1. アノテーションの管理

フロントエンドに追加情報を渡すには、属性をレンダリングする方法を決定するアノテーションで属性を切り分けることができます。この機能は、Red Hat Single Sign-On を拡張して、属性に関連付けられたアノテーションに基づいて動的にページをレンダリングする場合に便利です。このメカニズムは、たとえば 属性に Form input filed を設定するため に使用されます。

属性アノテーション

user profile annotation

5.11.4. 属性グループの管理

属性グループ サブタブで、属性グループを作成、編集、および削除できます。属性グループを使用すると、相関属性のコンテナーを定義でき、ユーザーに表示されるフォームで一緒にレンダリングできます。

属性グループリスト

user profile attribute group list

注記

属性にバインドされる属性グループを削除できません。そのため、最初に属性を更新してバインディングを削除する必要があります。

新規グループを作成するには、属性グループ一覧の右上にある Create ボタンをクリックします。

属性グループ設定

user profile create attribute group

グループを設定する際に、以下の設定を定義できます。

名前
グループの名前。
表示名
グループのユーザーフレンドリーな名前。主にユーザーに表示されるフォームをレンダリングする場合に使用されます。これは国際化をサポートするため、メッセージバンドルから値をロードできるようにします。
説明の表示
ユーザーに表示されるフォームをレンダリングする際にツールチップとして表示されるユーザーフレンドリーなテキストです。
Annotation
このセクションでは、アノテーションを属性に関連付けることができます。アノテーションは、レンダリングの目的で追加のメタデータをフロントエンドに渡すのに役立ちます。

5.11.5. JSON 設定の使用

ユーザープロファイル設定は、明確に定義された JSON スキーマを使用して保存されます。JSON Editor サブタブで直接ユーザープロファイル設定の編集を選択できます。

JSON 設定

user profile json config

JSON スキーマは以下のように定義されます。

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "roles": [ "user", "admin" ],
        "scopes": [ "foo", "bar" ]
      },
      "permissions": {
        "view": [ "admin", "user" ],
        "edit": [ "admin", "user" ]
      },
      "validations": {
        "email": {},
        "length": {
          "max": 255
        }
      },
      "annotations": {
        "myannotation": "myannotation-value"
      }
    }
  ],
  "groups": [
    {
      "name": "personalInfo",
      "displayHeader": "Personal Information"
    }
  ]
}

スキーマは、必要な数の属性をサポートします。

属性ごとに、name、オプションで requiredpermission、および annotations 設定を定義する必要があります。

5.11.5.1. 必須プロパティー

required 設定は、属性が必要であるかどうかを定義します。Red Hat Single Sign-On では、異なる条件に基づいて必要に応じて属性を設定することができます。

required 設定が空のオブジェクトとして定義されている場合には、属性は常に必要になります。

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {}
  ]
}

一方、ユーザーまたは管理者または両方に必要な属性の作成を選択できます。また、Red Hat Single Sign-On での認証時に、特定のスコープが要求される場合にのみ属性にマークを付けます。

ユーザーや管理者の必要に応じて属性にマークを付けるには、roles プロパティーを以下のように設定します。

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "roles": ["user"]
      }
  ]
}

roles プロパティーは、user または admin によって属性が必要であるかどうかによって、値が ユーザーまたは admin のいずれかである配列を想定します。

同様に、ユーザーの認証時に 1 つ以上のスコープのセットがクライアントによって要求される場合に、属性の作成を選択できます。そのため、以下のように scopes プロパティーを使用できます。

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "scopes": ["foo"]
      }
  ]
}

scopes プロパティーは、クライアントスコープを表す任意の文字列を持つことができます。

5.11.5.2. パーミッションプロパティー

属性レベルの permissions プロパティーを使用すると、属性への読み取りと書き込みのパーミッションを定義できます。パーミッションは、ユーザー、管理者、またはその両方の属性に対してこれらの操作を実行するかどうかに基づいて設定されます。

{
  "attributes": [
    {
      "name": "myattribute",
      "permissions": {
        "view": ["admin"],
        "edit": ["user"]
      }
  ]
}

view プロパティーと edit プロパティーはいずれも、 user または admin が表示可能または管理者が管理者が編集できるかによって、値がユーザーまたは admin のいずれかであることを想定します。

edit パーミッションが付与されると、view パーミッションは暗黙的に付与されます。

5.11.5.3. annotations プロパティー

属性レベルの annotation プロパティーを使用して、追加のメタデータを属性に関連付けることができます。アノテーションは、主に、ユーザープロファイル設定に基づいてユーザー属性のレンダリングに属性に関する追加情報を渡す場合に有用です。各アノテーションはキー/値のペアです。

{
  "attributes": [
    {
      "name": "myattribute",
      "annotations": {
        "foo": ["foo-value"],
        "bar": ["bar-value"]
      }
  ]
}

5.11.6. 動的フォームの使用

ユーザープロファイルの主な機能の 1 つは、属性メタデータに基づいてユーザーに表示されるフォームを動的にレンダリングすることがあります。機能がレルムで有効にされている場合、登録や更新などのフォームは、ユーザープロファイル設定に基づいてページを動的にレンダリングする特定のテーマテンプレートを使用してレンダリングされます。

ただし、デフォルトのレンダリングメカニズムがニーズに対応する場合は、すべてのテンプレートをカスタマイズする必要はありません。テーマのカスタマイズをまだ必要な場合には、以下で参照する必要があるテンプレートを以下に示します。

TemplateDescription

base/login/update-user-profile.ftl

更新プロファイルのページをレンダリングするテンプレート。

base/login/register-user-profile.ftl

登録ページをレンダリングするテンプレート。

base/login/idp-review-user-profile.ftl

ルールをレンダリングするテンプレートは、ブローカーを使用してユーザーをフェデレーションする際に、ユーザープロファイルをレビュー/更新するテンプレートです。

base/login/user-profile-commons.ftl

属性設定に基づいてフォームに入力フィールドをレンダリングするテンプレート。上記の 3 つのページテンプレートすべてから使用されます。ここで新しい入力タイプを実装できます。

デフォルトのレンダリングメカニズムでは、以下の機能を提供します。

  • 属性に設定されたパーミッションに基づいて、フィールドを動的に表示します。
  • 属性に設定された制約に基づいて、必須フィールドのマーカーを動的にレンダリングします。
  • 属性に設定されたフィールド入力タイプ (テキスト、日付、数値、選択、複数選択) を動的にレンダリングします。
  • 属性に設定されたパーミッションに応じて、読み取り専用フィールドを動的にレンダリングします。
  • 属性に設定された順序フィールドに応じて動的に順序フィールドが続きます。
  • 同じ属性グループに属する動的なグループフィールド。

5.11.6.1. 順序の属性

属性の順序は、属性一覧ページにあるときに上下矢印をクリックすると設定されます。

ordering 属性

user profile attribute list order

このページに設定した順番は、フィールドが動的形式でレンダリングされると考慮されます。

5.11.6.2. 属性のグループ化

動的フォームがレンダリングされると、同じ属性グループに属する属性をグループ化しようとします。

動的更新プロファイルフォーム

user profile update profile

注記

属性が属性グループにリンクされている場合、属性の順番も同じグループ内の属性が一緒に閉じられるようにすることが重要になります。それ以外の場合は、グループ内の属性に連続的な順序がない場合、同じグループヘッダーが動的形式で複数回レンダリングされる可能性があります。

5.11.6.3. 属性用のフォーム入力レポートの設定

Red Hat Single Sign-On は、動的フォームおよびその視覚化の他の側面で属性に使用される入力タイプを設定するための組み込みのアノテーションを提供します。

利用可能なアノテーションは以下のとおりです。

名前Description

inputType

フォーム入力フィールドのタイプ。利用可能なタイプは以下の表で説明されています。

inputHelperTextBefore

入力フィールドの前 (上) に表示されるヘルパーテキスト。ここでは、直接テキストまたは国際化パターン ($ {i18n.key}など) を使用できます。テキストはページにレンダリングされるときに html エスケープされないため、ここで html タグを使用してテキストをフォーマットできますが、html 制御文字を正しくエスケープする必要もあります。

inputHelperTextAfter

入力フィールドの後にレンダリングされるヘルパーテキスト。ここでは、直接テキストまたは国際化パターン ($ {i18n.key}など) を使用できます。テキストはページにレンダリングされるときに html エスケープされないため、ここで html タグを使用してテキストをフォーマットできますが、html 制御文字を正しくエスケープする必要もあります。

inputOptionsFromValidation

タイプを選択および複数選択するためのアノテーション。入力オプションの取得元となるカスタム属性検証のオプション名。詳しい説明 を参照してください。

inputOptionLabelsI18nPrefix

タイプを選択および複数選択するためのアノテーション。UI でオプションをレンダリングする国際化キープレフィックス。詳しい説明 を参照してください。

inputOptionLabels

タイプを選択および複数選択するためのアノテーション。オプションの UI ラベルを定義するためのオプションのマップ (直接または国際化を使用)。詳しい説明 を参照してください。

inputTypePlaceholder

フィールドに適用される HTML 入力 placeholder 属性: 入力フィールドの期待値を説明する短いヒントを指定します (たとえば、サンプル値または期待される形式の簡単な説明)。ユーザーが値を入力する前に、入力フィールドに短いヒントが表示されます。

inputTypeSize

フィールドに適用される HTML 入力 size 属性: 単一行の入力フィールドの幅を文字数で指定します。HTML selectタイプに基づくフィールドの場合は、オプションが表示された行数を指定します。使用されているテーマにある css によっては、機能しない場合があります。

inputTypeCols

フィールドに適用される HTML 入力 cols 属性: textarea タイプの幅 を文字数で指定します。使用されているテーマにある css によっては、機能しない場合があります。

inputTypeRows

フィールドに適用される HTML 入力 rows 属性: textarea タイプの高さを文字数で指定します。選択フィールドの場合は、オプションが表示された行数を指定します。使用されているテーマにある css によっては、機能しない場合があります。

inputTypePattern

クライアント側の検証を提供するフィールドに適用される HTML 入力 pattern 属性: 入力フィールドの値がチェックされる正規表現を指定します。単一行入力に役立ちます。

inputTypeMaxLength

クライアント側の検証を提供するフィールドに適用される HTML 入力 maxlength 属性: 入力フィールドに入力できるテキストの最大長。テキストフィールドで役に立ちます。

inputTypeMinLength

クライアント側の検証を提供するフィールドに適用される HTML 入力 minlength 属性: 入力フィールドに入力できるテキストの最小長。テキストフィールドで役に立ちます。

inputTypeMax

クライアント側の検証を提供するフィールドに適用される HTML 入力 max 属性: 入力フィールドに入力できる最大値。数値フィールドに役立ちます。

inputTypeMin

クライアント側の検証を提供するフィールドに適用される HTML 入力 min 属性: 入力フィールドに入力できる最小値。数値フィールドに役立ちます。

inputTypeStep

フィールドに適用される HTML 入力 step属性: 入力フィールドの有効な数値間の間隔を指定します。数値フィールドに役立ちます。

注記

フィールドタイプは、HTML フォームフィールドタグとそれに適用される属性を使用します。フィールドタイプは、HTML 仕様とブラウザーサポートに基づいて動作します。

ビジュアルレンダリングは、使用するテーマに適用されている css スタイルにも依存します。

利用可能な inputType アノテーションの値:

名前Description使用される HTML タグ

text

単一行のテキスト入力。

input

textarea

複数の行テキスト入力。

textarea

select

一般的な単一の選択入力。以下の オプションの設定方法の説明 を参照してください。

select

select-radiobuttons

ラジオボタンをグループ化して入力を 1 つ選択します。以下の オプションの設定方法の説明 を参照してください。

入力グループ

複数選択

一般的な複数選択入力。以下の オプションの設定方法の説明 を参照してください。

select

multiselect-checkboxes

チェックボックスのグループで入力を複数選択します。以下の オプションの設定方法の説明 を参照してください。

入力グループ

html5-email

HTML 5 仕様に基づくメールアドレスの単一行のテキスト入力。

input

html5-tel

HTML 5 仕様に基づく電話番号の単一行のテキスト入力。

input

html5-url

HTML 5 仕様に基づく URL の単一行のテキスト入力。

input

html5-number

HTML 5 仕様に基づく数値 (stepに応じて整数または浮動小数点) の 1 行入力。

input

html5-range

HTML 5 仕様に基づいて入力した数字のスライダー。

input

html5-datetime-local

HTML 5 仕様に基づく日付入力。

input

html5-date

HTML 5 仕様に基づく日付入力。

input

html5-month

HTML 5 仕様に基づいた月入力。

input

html5-week

HTML 5 仕様に基づく週入力。

input

html5-time

HTML 5 仕様に基づく時間入力。

input

5.11.6.3.1. select フィールドおよび multiselect フィールドのオプションの定義

選択フィールドと複数選択フィールドのオプションは、属性に適用された検証から取得され、UI に表示される検証とフィールドオプションが常に一貫していることを確認します。デフォルトでは、オプションは組み込み options の検証から取得されます。

さまざまな方法を使用して、人間が判読できるラベルを選択およびマルチ選択オプションで提供できます。最も単純なケースでは、属性値が UI ラベルと同じである場合です。この場合、追加の設定は必要ありません。

オプションの値は UI ラベルと同じです。

user profile select options simple

属性値が UI に適さない ID の種類である場合、inputOptionLabelsI18nPrefix アノテーションによって提供される単純な国際化サポートを使用できます。これは国際化キーのプレフィックスを定義します。オプション値はこの接頭辞に追加されるドットになります。

i18n キー接頭辞を使用した UI ラベルの簡単な国際化

user profile select options simple i18n

オプション値のローカライズされた UI ラベルテキストは、一般的なローカリゼーションメカニズムを使用して、userprofile.jobtitle.sweng キーおよび userprofile.jobtitle.swarch キーで提供する必要があります。

inputOptionLabels アノテーションを使用して、個別のオプションのラベルを指定することもできます。オプションのラベルのマップが含まれています - マップのキーはオプション値 (検証で定義) であり、マップの値は UI ラベルテキスト自体またはそのオプションの国際化パターン ($ {i18n.key} など) です。

注記

User Profile JSON Editor を使用して map を inputOptionLabels アノテーションの値として入力する必要があります。

国際化なしで各オプションの直接入力されたラベルの例:

"attributes": [
...
{
  "name": "jobTitle",
  "validations": {
    "options": {
      "options":[
        "sweng",
        "swarch"
      ]
    }
  },
  "annotations": {
    "inputType": "select",
    "inputOptionLabels": {
      "sweng": "Software Engineer",
      "swarch": "Software Architect"
    }
  }
}
...
]

個別オプションの国際化されたラベルの例:

"attributes": [
...
{
  "name": "jobTitle",
  "validations": {
    "options": {
      "options":[
        "sweng",
        "swarch"
      ]
    }
  },
  "annotations": {
    "inputType": "select-radiobuttons",
    "inputOptionLabels": {
      "sweng": "${jobtitle.swengineer}",
      "swarch": "${jobtitle.swarchitect}"
    }
  }
}
...
]

ローカライズされたテキストは、一般的なローカリゼーションメカニズムを使用して、jobtitle.swengineer キーと jobtitle.swarchitect キーで提供する必要があります。

inputOptionsFromValidation 属性アノテーションのおかげで、カスタムバリデーターを使用してオプションを提供できます。この検証には、オプションの配列を提供する options 設定が必要です。国際化は、組み込みの options 検証によって提供されるオプションの場合と同じように機能します。

カスタムバリデーターが提供するオプション

user profile select options custom validator

5.11.7. ユーザープロファイルのコンプライアンスの強制

ユーザープロファイルが設定に準拠していることを確認するには、管理者は VerifyProfile の必須のアクションを使用して、最終的に Red Hat Single Sign-On への認証時にプロファイルの更新を強制することができます。

注記

VerifyProfile アクションは UpdateProfile アクションに似ています。ただし、ユーザープロファイルが提供するすべての機能を活用して、ユーザープロファイルの設定により自動的にコンプライアンスが強制されます。

有効にすると、ユーザー認証時に VerifyProfile アクションは以下の手順を実行します。

  • ユーザープロファイルが、レルムに設定されたユーザープロファイル設定に完全準拠しているかどうかを確認します。
  • そうでない場合には、認証中に追加のステップを実行して、ユーザーが不足している属性や無効な属性を更新できるようにします。
  • ユーザープロファイルが設定に準拠する場合は、追加のステップが実行されず、ユーザーは認証プロセスを続行します。

デフォルトでは、VerifyProfile アクションは無効になっています。これを有効にするには、左側のメニューの Authentication リンクをクリックしてから、Required Actions タブをクリックします。このタブで Register ボタンをクリックし、VerifyProfile アクションを選択します。

VerifyProfile Required Action の再入力

user profile register verify profile action

5.11.8. ユーザープロファイルへの移行

レルムにユーザープロファイル機能を有効にする前に、いくつかの重要な考慮事項に注意してください。属性メタデータを管理する単一の場所を提供することで、ユーザーや管理方法に設定できる属性は非常に厳しいものです。

ユーザー管理では、管理者はユーザープロファイル設定で定義された属性のみを管理できます。ユーザープロファイル設定で定義されておらず、ユーザープロファイル設定で定義されていない他の属性にはアクセスできません。ユーザーまたは管理者へ公開する必要のあるすべてのユーザー属性で、ユーザープロファイル設定を更新することが推奨されます。

ユーザー情報をクエリーするために、ユーザー REST API にアクセスする場合も同じ推奨事項が適用されます。

LDAP_IDLDAP_ENTRY_DNKERBEROS_ PRINCIPAL などの Red Hat Single Sign-On 内部ユーザー属性に関しては、これらの属性をユーザープロファイル設定の属性としてアクセスできるようにする必要があります。表示可能な属性は管理者だけなので、管理コンソールを使用してユーザー属性を管理する場合や、ユーザー API でユーザーのクエリーを行う際には、この属性を表示可能としてマークすることが推奨されます。

そのため、レガシーテンプレート (ユーザー root 属性でハードコード化) へのカスタマイズがある場合、ユーザーに表示されるフォームをレンダリングする場合、これらのフォームを動的にレンダリングする新規テンプレートは使用されません。理想的には、テンプレートへのカスタマイズは回避し、これらの新規テンプレートが提供する動作のスタップをして、フォームを動的にレンダリングする必要があります。要件への対応が十分ではない場合は、それらをカスタマイズするか、フィードバックを提供してください。これにより、新しいテンプレートを拡張することが理にかっているかどうかについて話し合うことができます。

5.12. Red Hat Single Sign-On により収集された個人データ

デフォルトでは、Red Hat Single Sign-On は以下のデータを収集します。

  • ユーザーの電子メール、名字、姓など、基本的なユーザープロファイルデータ。
  • ソーシャルログインの使用時にソーシャルアカウントに使用する基本的なユーザープロファイルデータとソーシャルアカウントへの参照。
  • IP アドレス、オペレーティングシステム名、ブラウザー名など、監査およびセキュリティー上の目的で収集されるデバイス情報

Red Hat Single Sign-On で収集される情報は、非常にカスタマイズ可能になりました。カスタマイズを行う際には、以下のガイドラインが適用されます。

  • 登録フォームやアカウントフォームには、誕生日、性別、国籍などのカスタムフィールドを含めることができます。管理者は Red Hat Single Sign-On を設定して、LDAP などのソーシャルプロバイダーまたはユーザーストレージプロバイダーからデータを取得できます。
  • Red Hat Single Sign-On は、パスワード、OTP コード、WebAuthn 公開鍵などのユーザーの認証情報を収集します。この情報は暗号化されてデータベースに保存されるため、Red Hat Single Sign-On の管理者には表示されないことがありません。それぞれの種類の認証情報には、パスワードのハッシュに使用されるアルゴリズムやパスワードのハッシュ化に使用されるハッシュ反復数など、管理者が見直す可能性がある、自信的なメタデータを含めることができます。
  • 認証サービスおよび UMA サポートを有効にすると、Red Hat Single Sign-On は、特定のユーザーが所有者であるオブジェクトに関する情報を保持できます。

第6章 ユーザーセッションの管理

ユーザーがレルムにログインすると、Red Hat Single Sign-On は各ユーザーのユーザーセッションを維持し、セッション内でユーザーがアクセスする各クライアントが記憶します。レルム管理者は、各ユーザーセッションで複数のアクションを実行できます。

  • レルムのログイン統計を表示します。
  • アクティブユーザー、およびログイン先のユーザーを表示します。
  • セッションからユーザーをログアウトします。
  • トークンを取り消します。
  • トークンのタイムアウトを設定します。
  • セッションタイムアウトを設定します。

6.1. セッションの管理

Red Hat Single Sign-On でアクティブなクライアントおよびセッションのトップレベルビューを表示するには、メニューから Sessions をクリックします。

セッション

Sessions

6.1.1. Logout all 操作

Logout all ボタンをクリックして、レルム内の全ユーザーを省略できます。

Logout all ボタンをクリックすると、すべての SSO クッキーは無効になり、アクティブなブラウザーセッション内で認証を要求するクライアントは再度ログインする必要があります。Red Hat Single Sign-On は、ログアウトイベントの Red Hat Single Sign-On OIDC クライアントアダプターを使用してクライアントを通知します。SAML などのクライアントタイプは、バックチャネルログアウト要求を受信しません。

注記

Logout all をクリックしても、未処理のアクセストークンは取り消しません。未処理のトークンは自然に期限切れになる必要があります。Red Hat Single Sign-On OIDC クライアントアダプターを使用するクライアントの場合は、失効ポリシー をプッシュしてトークンを取り消すことができますが、これは他のアダプターでは機能しません。

6.1.2. アプリケーションナビゲーション

Sessions ページで、各クライアントをクリックして、そのクライアントの Sessions タブに移動します。Show Sessions ボタンをクリックして、アプリケーションにあるユーザーを表示します。

アプリケーションセッション

application sessions

6.1.3. ユーザーナビゲーション

個々のユーザーの Sessions タブに移動した場合は、ユーザーのセッション情報を表示することもできます。

ユーザーセッション

user sessions

6.2. 失効ポリシー

システムが危険にさらされたら、Sessions 画面の Revocation タブをクリックすると、アクティブなセッションおよびアクセストークンをすべて取り消すことができます。

取り消し

revocation

このコンソールを使用して、その時刻と日付よりも前に発行したセッションまたはトークンが無効である日時を指定できます。今すぐ Set をクリックして、ポリシーを現在の日時に設定します。Push をクリックし、この失効ポリシーを Red Hat Single Sign-On OIDC クライアントに登録されている OIDC クライアントにプッシュします。

6.3. セッションおよびトークンのタイムアウト

Red Hat Single Sign-On には、Realm Settings メニューの Tokens タブを使用してセッション、クッキー、およびトークンのタイムアウトを制御できます。

tokens タブ

tokens tab

設定説明

デフォルトの署名アルゴリズム

レルムにトークンを割り当てるために使用されるデフォルトのアルゴリズム。

トークンの更新の取り消し

ON にすると、Red Hat Single Sign-On はトークンの更新をキャンセルし、クライアントが使用する必要のある別のトークンを発行します。このアクションは、更新トークンフローを実行する OIDC クライアントに適用されます。

SSO Session Idle

この設定は OIDC クライアントのみを対象としています。ユーザーがこのタイムアウトよりも非アクティブである場合は、ユーザーセッションが無効になります。このタイムアウト値は、クライアントが認証を要求するか、更新トークン要求を送信するときにリセットされます。Red Hat Single Sign-On は、セッションの無効化が有効になる前に、アイドルタイムアウトに期間を追加します。詳細は、後述する 注記 を参照してください。

SSO セッション最大

ユーザーセッションが期限切れになるまでの最大時間。

SSO Session Idle Remember Me

この設定は標準の SSO セッション ID 設定に似ていますが、Remember Me が有効になっているログインに固有の設定です。ユーザーは、ログイン時に Remember Me をクリックすると、セッションのアイドルタイムアウトが長く指定できます。この設定は任意の設定であり、その値がゼロより大きい場合、SSO Session Idle 設定と同じアイドルタイムアウトを使用します。

SSO Session Max Remember Me

この設定は標準の SSO セッション Max と似ていますが、Remember Me ログインに 固有です。ユーザーは、ログイン時に Remember Me をクリックするとセッションが長く指定できます。この設定は任意の設定であり、その値がゼロより大きい場合、SSO Session Max 設定と同じセッションライフスパンを使用します。

オフラインセッションのアイドリング

この設定は オフラインアクセス用です。Red Hat Single Sign-On がオフライントークンを取り消す前にセッションがアイドル状態のままになる時間。Red Hat Single Sign-On は、セッションの無効化が有効になる前に、アイドルタイムアウトに期間を追加します。詳細は、後述する 注記 を参照してください。

オフラインセッションの最大制限

この設定は オフラインアクセス用です。このフラグが ON の場合、ユーザーアクティビティーに関係なく、オフラインセッション Max がアクティブな状態のままの最大時間を制御できます。Client Offline Session Idle および Client Offline Session Max が有効化されています。

オフラインセッションの最大

この設定はオフラインアクセス用で、Red Hat Single Sign-On が対応するオフライントークンを取り消すまでの最大時間です。このオプションは、ユーザーアクティビティーに関係なく、オフライントークンがアクティブな状態のままになる最大期間を制御します。

Client Offline Session Idle

この設定は オフラインアクセス用です。ユーザーがこのタイムアウトよりも非アクティブである場合、オフラインのトークンがアイドル状態のタイムアウトを上げます。この設定は、オフラインセッションアイドルよりもオフライントークンのアイドルタイムアウトを短く指定します。ユーザーは、個別のクライアントに対してこの設定を上書きできます。この設定は任意の設定であり、ゼロに設定すると Offline Session Idle 設定で同じアイドルタイムアウトを使用します。

Client Offline Session Max

この設定は オフラインアクセス用です。オフライントークンの有効期限が切れるまでの最大時間。この設定は、オフラインセッションタイムアウトよりも短いトークンのタイムアウトを指定しますが、ユーザーは個別のクライアントに対して上書きできます。この設定は任意の設定であり、ゼロに設定すると Offline Session Max 設定で同じアイドルタイムアウトを使用します。

クライアントセッション ID

ユーザーがこのタイムアウトよりも非アクティブである場合、更新トークンはアイドル状態のタイムアウトを上げます。この設定は、セッションアイドルタイムアウトよりも、更新トークンのアイドルタイムアウトを短くし、ユーザーは個別のクライアントに対して上書きできます。この設定は任意の設定であり、ゼロに設定すると SSO セッション ID 設定で同じアイドルタイムアウトを使用します。

クライアントセッション数

更新トークンの有効期限が切れるまでの最大時間。この設定は、セッションタイムアウトよりも更新トークンのタイムアウトを短くし、ユーザーは個別のクライアントに対して上書きできます。この設定は任意の設定であり、ゼロに設定すると SSO セッション Max 設定で同じアイドルタイムアウトを使用します。

アクセストークンの寿命

Red Hat Single Sign-On が OIDC アクセストークンを作成すると、この値はトークンの有効期間を制御します。

インプリシットフロー (Implicit Flow) のアクセストークンのライフサイクル

インプリシットフローでは、Red Hat Single Sign-On は更新トークンを提供しません。Implicit Flow によって作成されるアクセストークンに別のタイムアウトが存在します。

クライアントログインのタイムアウト

クライアントが OIDC で Authorization Code Flow を終了するまでの最大時間。

ログインのタイムアウト

ロギングにかかる合計時間。認証にかかる時間よりも長い場合は、ユーザーは認証プロセスを再度開始する必要があります。

ログインアクションのタイムアウト

Maximum time ユーザーは、認証プロセス中に 1 つのページで費やすことができます。

ユーザーによる開始に関するアクションライフスパン

ユーザーのアクションパーミッションの有効期限が切れるまでの最大時間。ユーザーが通常、自己作成のアクションに迅速に対応するので、この値を短くしてください。

デフォルトの管理者開始アクションのライフサイクル

管理者によってユーザーに送信されるアクションパーミッションの最大時間。この値を長く維持して、管理者がオフラインユーザーに電子メールを送信できるようにします。管理者は、トークンを発行する前にデフォルトのタイムアウトを上書きできます。

ユーザーによる開始処理のオーバーライド

各操作ごとに独立したタイムアウトを指定します (たとえば、パスワード、ユーザーアクション、アイデンティティープロバイダーの E-mail Verification など)。デフォルト値は、User-Initiated Action Lifespan で設定される値に設定されます。

注記

アイドルタイムアウトの場合は、セッションがアクティブである期間が 2 分のウィンドウになります。たとえば、タイムアウトが 30 分に設定されている場合、セッションの有効期限が切れるまでに 32 分になります。

このアクションは、クラスター間および複数のデータセンター環境で必要です。この場合、トークンは有効期限前に 1 つのクラスターノードで短期間に更新され、他のクラスターノードは更新されたノードから正常な更新についてのメッセージを受信していないため、セッションが期限切れと誤って考慮されます。

6.4. オフラインアクセス

オフラインアクセスログイン時に、クライアントアプリケーションは更新トークンではなくオフライントークンを要求します。クライアントアプリケーションは、このオフライントークンを保存し、ユーザーがログアウトした場合に今後のログインに使用できます。このアクションは、ユーザーがオンラインにない場合でも、アプリケーションがユーザーの代わりにオフライン操作を実行する必要がある場合に便利です。たとえば、通常のデータバックアップです。

クライアントアプリケーションは、ストレージでオフライントークンを永続化し、これを使用して Red Hat Single Sign-On サーバーから新しいアクセストークンを取得します。

更新トークンとオフライントークンの相違点は、オフライントークンの期限が切れず、SSO Session Idle timeout および SSO Session Max lifespan の対象でないことです。オフライントークンは、ユーザーのログアウトまたはサーバーの再起動後に有効になります。更新トークンアクションには、30日ごとに 1 回、または Offline Session Idle の値にオフライントークンを使用する必要があります。

Offline Session Max Limited を有効にすると、更新トークンアクションにオフライントークンを使用していても、オフライントークンが 60 日後に有効期限が切れます。管理コンソールの Offline Session Max の値を変更できます。

Revoke Refresh Token オプションを有効にすると、各オフライントークンを 1 回だけ使用できます。更新後、前の 1 つではなく、更新応答から新しいオフライントークンを保存する必要があります。

ユーザーは、Red Hat Single Sign-On がユーザーアカウントのコンソールで付与するオフライントークンを表示し、取り消すことができます。管理者は、Consents タブで 管理コンソールの個々のユーザーのオフライントークンを取り消すことができます。管理者は、各クライアントの Offline Access タブで発行されたオフライントークンすべてを表示できます。管理者は、失効ポリシーを設定してオフライントークンを取り消すことができます。

オフライントークンを発行するには、ユーザーは realm-level offline_access ロールのロールマッピングが必要です。クライアントには、そのロールをスコープで割り当てる必要もあります。クライアントは、offline_access クライアント スコープを Optional client scope としてロールに追加し、デフォルトでは実行する必要があります。

クライアントは、承認要求を Red Hat Single Sign-On に送信するときに scope=offline_access パラメーターを追加することでオフライントークンを要求できます。Red Hat Single Sign-On OIDC クライアントアダプターは、アプリケーションのセキュアな URL (例: http://localhost:8080/customer-portal/secured?scope=offline_access) にアクセスするために使用すると、このパラメーターを自動的に追加します。認証要求の本文に scope=offline_access が含まれている場合、Direct Access Grant および Service Accounts はオフライントークンをサポートします。

6.5. 一時的なセッション

Red Hat Single Sign-On で一時的なセッションを実行できます。一時的なセッションを使用する場合、Red Hat Single Sign-On は認証に成功した後にユーザーセッションを作成しません。Red Hat Single Sign-On は、ユーザーを正常に認証する現在のリクエストのスコープに対して一時的な一時的なセッションを作成します。Red Hat Single Sign-On は、認証後に一時セッションを使用して プロトコルマッパー を実行できます。

一時的なセッションでは、クライアントアプリケーションはトークンを更新したり、トークンイントロスペクションしたり、特定のセッションを検証したりすることはできません。これらのアクションは不要な場合があるため、ユーザーセッションを永続化するための追加のリソースの使用を避けることができます。このセッションは、パフォーマンス、メモリー、ネットワーク通信 (クラスターおよびクロスデータセンター環境) のリソースを保存します。

第7章 ロールおよびグループを使用したパーミッションおよびアクセスの割り当て

ロールとグループには同様の目的があります。この目的は、ユーザーにアプリケーションを使用するためのアクセスと権限を与えることです。グループは、ロールと属性を適用するユーザーの集まりです。ロールは、特定のアプリケーションのパーミッションおよびアクセス制御を定義します。

通常、ロールはユーザーの 1 種別に適用されます。たとえば、組織には adminusermanageremployee のロールが含まれます。アプリケーションは、ロールにアクセスとパーミッションを割り当て、ユーザーが同じアクセスとパーミッションを持つように複数のユーザーを割り当てることができます。たとえば、管理コンソールには、管理コンソールの異なる部分にアクセスするための権限を付与するロールがあります。

また、ロールのグローバル名前空間があり、各クライアントにはロールを定義する独自の専用の名前空間もあります。

7.1. レルムロールの作成

レルムレベルのロールは、ロールを定義する namespace です。ロールの一覧を表示するには、メニューで Roles をクリックします。

roles

手順

  1. Add Role をクリックします。
  2. Role Name を入力します。
  3. Description を入力します。
  4. Save をクリックします。

ロールの追加

Add role

description フィールドには、${var-name} 文字列の置換変数を指定して、ローカル化できます。ローカライズされた値は themes プロパティーファイル内のテーマに設定されています。詳細は サーバー開発者ガイド を参照してください。

7.2. クライアントロール

クライアントロールはクライアント専用の namespace です。各クライアントは独自の名前空間を取得します。クライアントロールは、各クライアントの Roles タブで管理されます。この UI は、レルムレベルのロールの場合と同じように対話します。

7.3. ロールの複合ロールへの変換

レルムまたはクライアントレベルのロールは 複合ロール になります。複合ロールは、1 つ以上の追加ロールに関連付けられたロールです。複合ロールがユーザーにマップされると、ユーザーは複合ロールに関連付けられたロールを取得します。この継承は再帰的であるため、ユーザーは複合の複合も継承します。ただし、複合ロールが使用されないことを推奨します。

手順

  1. メニューで Roles をクリックします。
  2. 変換するロールをクリックします。
  3. 複合ロールON に切り替えます。

複合ロール

Composite role

ロール選択 UI がページに表示され、レルムレベルとクライアントレベルのロールを、作成する複合ロールに関連付けることができます。

この例では、従業員の レルムレベルロールが 開発者 の複合ロールに関連付けられます。developer ロールを持つユーザーは、employee ロールも継承します。

注記

トークンと SAML アサーションの作成時に、複合には、クライアントに送信された認証応答の要求およびアサーションにも関連付けられたロールが追加されます。

7.4. ロールマッピングの割り当て

ユーザーの Role Mappings タブからユーザーにロールマッピングを割り当てることができます。

手順

  1. メニューの Users をクリックします。
  2. ロールマッピングを実行するユーザーをクリックします。ユーザーが表示されない場合は、View all users をクリックします。
  3. Role Mappings タブをクリックします。
  4. 利用可能なロール ボックスで、ユーザーに割り当てるロールをクリックします。
  5. Add selected をクリックします。

ロールマッピング

Role mappings

上記の例では、複合ロールの開発者を ユーザー に割り当てます。このロールは、複合ロール トピックで作成されました。

有効なロールマッピング

Effective role mappings

developer ロールが割り当てられていると、developer 複合に関連する employee ロールが Effective Roles ボックスに表示されます。実効ロールとは、複合から継承されたユーザーとロールに明示的に割り当てられるロールのことです。

7.5. デフォルトロールの使用

デフォルトのロールを使用して、ユーザーが Identity Brokering で作成またはインポートされる場合にユーザーロールマッピングを自動的に割り当てます。

手順

  1. メニューで Roles をクリックします。
  2. Default Roles タブをクリックします。

デフォルトロール

Default roles

このスクリーンショットは、一部の デフォルトロール がすでに存在していることを示しています。

7.6. ロールマッピングのマッピング

OIDC アクセストークンまたは SAML アサーションの作成時に、ユーザーロールマッピングはトークンまたはアサーション内で要求されます。アプリケーションはこれらの要求を使用して、アプリケーションが制御するリソースにアクセスの決定を行います。Red Hat Single Sign-On は、アクセストークンとアプリケーションを再度使用して、リモートでセキュアな REST サービスを呼び出します。ただし、これらのトークンには関連するリスクがあります。攻撃者はこれらのトークンを取得し、パーミッションを使用してネットワークを危険にさらすことができます。この状況を防ぐには、Role Scope Mappings を使用します。

ロールスコープマッピングは、アクセストークン内に宣言されたロールを制限します。クライアントがユーザー認証を要求すると、受信するアクセストークンには、クライアントのスコープに対して明示的に指定されるロールマッピングのみが含まれます。その結果、すべてのユーザーのパーミッションにクライアントアクセスを付与するのではなく、個々のアクセストークンのパーミッションを制限するようになります。

デフォルトでは、各クライアントはユーザーのすべてのロールマッピングを取得します。各クライアントの Scope タブでロールマッピングを表示できます。

フルサポート

Full scope

デフォルトでは、スコープの有効なロールはすべてレルムで宣言されるロールです。このデフォルトの動作を変更するには、Full Scope AllowedON に切り替え、クライアントごとに必要な特定のロールを宣言します。クライアントスコープ を使用して、クライアントのセットに同じロールスコープマッピングを定義することもできます。

部分的なスコープ

Partial scope

7.7. グループ

Red Hat Single Sign-On のグループは、各ユーザーに共通の属性とロールマッピングのセットを管理します。ユーザーは任意の数のグループのメンバーとなり、各グループに割り当てられた属性およびロールマッピングを継承できます。

グループを管理するには、メニューで Groups をクリックします。

グループ

groups

グループは階層です。グループには複数のサブグループを指定できますが、グループには親を 1 つだけ指定できます。サブグループは、親から属性とロールマッピングを継承します。ユーザーは、親から属性とロールマッピングも継承します。

親グループと子グループがあり、子グループにのみ所属するユーザーがある場合は、子グループのユーザーは、親グループと子グループの両方の属性とロールマッピングを継承します。

以下の例には、トップレベル セールス グループと子の 北アメリカ のサブグループが含まれます。

グループを追加するには、以下を実行します。

  1. グループをクリックします。
  2. New をクリックします。
  3. ツリーで Groups アイコンを選択して、トップレベルのグループを作成します。
  4. Create Group 画面にグループ名を入力します。
  5. Save をクリックします。

    グループ管理ページが表示されます。

    Group

    group

定義する属性およびロールマッピングは、グループのメンバーであるグループおよびユーザーによって継承されます。

ユーザーをグループに追加します。

  1. メニューの Users をクリックします。
  2. ロールマッピングを実行するユーザーをクリックします。ユーザーが表示されない場合は、View all users をクリックします。
  3. Groups をクリックします。

    ユーザーグループ

    user groups

  4. Available Groups ツリーからグループを選択します。
  5. 参加 をクリックします。

ユーザーからグループを削除するには、以下を実行します。

  1. Group Membership ツリーからグループを選択します。
  2. Leave をクリックします。

この例では、ユーザー jimlincolnNorth America グループにあります。グループの Members タブの下に jimlincoln が表示されます。

グループメンバーシップ

group membership

7.7.1. ロールと比べているグループ

グループとロールには、いくつかの類似点と違いがあります。Red Hat Single Sign-On では、グループはロールおよび属性を適用するユーザーのコレクションです。ロールは、ユーザーとアプリケーションのタイプを定義し、パーミッションをロールに割り当てます。

複合ロールは、同じ機能を提供するグループに似ています。その違いは概念的です。複合ロールは、パーミッションモデルをサービスやアプリケーションのセットに適用します。複合ロールを使用してアプリケーションおよびサービスを管理します。

グループは、組織におけるユーザーとロールのコレクションに重点を置きます。グループを使用してユーザーを管理します。

7.7.2. デフォルトグループの使用

グループメンバーシップを、Identity Brokering で作成またはインポートするユーザーに自動的に割り当てるには、デフォルトのグループを使用します。

  1. メニューの Groups をクリックします。
  2. Default Groups タブをクリックします。

デフォルトグループ

Default groups

このスクリーンショットは、一部の デフォルトグループ がすでに存在していることを示しています。

第8章 認証の設定

本章では、複数の認証トピックについて説明します。以下のトピックを以下に示します。

  • 厳密なパスワードおよびワンタイムパスワード (OTP) ポリシーを強制します。
  • 異なる認証情報タイプの管理
  • Kerberos でログインします。
  • 組み込み認証情報タイプを無効にして有効化します。

8.1. パスワードポリシー

Red Hat Single Sign-On がレルムを作成すると、パスワードポリシーとレルムは関連付けられません。長さ、セキュリティー、または複雑性に制限のない簡単なパスワードを設定できます。実稼働環境では、シンプルなパスワードは受け入れられません。Red Hat Single Sign-On には、管理コンソールで利用可能なパスワードポリシーセットがあります。

手順

  1. メニューで Authentication をクリックします。
  2. Password Policy タブをクリックします。
  3. Add policy ドロップダウンボックスで、追加するポリシーを選択します。
  4. 選択した ポリシー値 の値を入力します。
  5. Save をクリックします。

    パスワードポリシー Password Policy

ポリシーを保存した後、Red Hat Single Sign-On は新しいユーザーにポリシーを適用し、既存のユーザーに Update Password アクションを設定し、次回ログイン時にパスワードを変更します。以下に例を示します。

パスワードポリシーに失敗しました。

Failed Password Policy

8.1.1. パスワードポリシータイプ

8.1.1.1. ハッシュアルゴリズム

パスワードはクリアテキストで保存されません。ストレージまたは検証の前に、標準のハッシュアルゴリズムを使用する Red Hat Single Sign-On ハッシュパスワードである PBKDF2、PBKDF2-SHA256、および PBKDF-SHA512 ハッシュアルゴリズムをサポートする Red Hat Single Sign-On ハッシュパスワード。

8.1.1.2. ハッシュの反復

ストレージまたは検証の前に Red Hat Single Sign-On ハッシュパスワードの数を指定します。デフォルト値は 27,500 です。

Red Hat Single Sign-On ハッシュパスワード。パスワードデータベースへのアクセスを持つアクターが、リバースエンジニアリングを通じてパスワードを読み取ることができないようにします。

注記

ハッシュの反復値が高いと、CPU のべき乗を増やす必要があるため、パフォーマンスに影響する可能性があります。

8.1.1.3. 数字

パスワード文字列に必要な数字の数。

8.1.1.4. 小文字

パスワード文字列に必要な小文字の数。

8.1.1.5. 大文字

パスワード文字列に必要な大文字の数。

8.1.1.6. 特殊文字

パスワード文字列で必要な特殊文字の数。

8.1.1.7. ユーザー名なし

パスワードはユーザー名と同じにすることはできません。

8.1.1.8. メールなし

パスワードは、ユーザーのメールアドレスと同じにすることはできません。

8.1.1.9. 正規表現

パスワードは、定義済みの正規表現パターンを 1 つ以上一致させる必要があります。

8.1.1.10. パスワードが失効する

パスワードが有効な日数。有効期限が切れた日数が経過したら、パスワードを変更する必要があります。

8.1.1.11. 最近使用されていない

ユーザーがパスワードを使用できない。Red Hat Single Sign-On は、使用したパスワードの履歴を保存します。保存される古いパスワードの数は Red Hat Single Sign-On で設定可能です。

8.1.1.12. パスワードのブラックリスト

パスワードをブラックリストファイルに含めることはできません。

  • ブラックリストファイルは、Unix 行で終わる UTF-8 プレーンテキストファイルです。すべての行は、ブラックリストに指定されたパスワードを表します。
  • Red Hat Single Sign-On は、大文字と小文字を区別しない方法でパスワードを比較します。ブラックリストのすべてのパスワードは小文字でなければなりません。
  • blacklist ファイルの値は、ブラックリストファイルの名前でなければなりません。
  • ブラックリストファイルは、デフォルトで ${jboss.server.data.dir}/password-blacklists/ に対して解決します。以下を使用して、このパスをカスタマイズします。

    • keycloak.password.blacklists.path プロパティー。
    • passwordBlacklist ポリシー SPI 設定の blacklistsPath プロパティー。

8.2. ワンタイムパスワード (OTP) ポリシー

Red Hat Single Sign-On には、FreeOTP または Google Authenticator One-Time Password ジェネレーターを設定するポリシーが複数あります。Authentication メニューをクリックし、OTP Policy タブをクリックします。

OTP ポリシー

OTP Policy

Red Hat Single Sign-On は、OTP Policy タブに設定した情報に基づいて、OTP セットアップページで QR コードを生成します。FreeOTP および Google Authenticator は、OTP の設定時に QR コードをスキャンします。

8.2.1. 時間ベースまたはカウンターベースのワンタイムパスワード

OTP ジェネレーターに Red Hat Single Sign-On で利用可能なアルゴリズムは時間ベースで、カウンターベースになっています。

タイムベースのワンタイムパスワード (TOTP) を使用すると、トークンジェネレーターは現在の時刻と共有秘密をハッシュ化します。サーバーは、ウィンドウ内のハッシュを送信した値と比較することにより、OTP を検証します。TOTP は短時間に有効です。

Counter-Based One Time Passwords (HOTP) では、Red Hat Single Sign-On は現在の時間ではなく、共有カウンターを使用します。Red Hat Single Sign-On サーバーは、成功した各 OTP ログインでカウンターをインクリメントします。ログインに成功した後、有効な OTP が変更されます。

一致可能な OTP は短時間で有効になり、OTP for HOTP は終了期間に有効であるため、TOTP は HOTP よりも安全です。OTP に入るのに時間制限が存在しないため、HOTP は TOTP よりも使いやすいことです。

HOTP では、サーバーがカウンターをインクリメントするたびにデータベースの更新が必要になります。この更新は、負荷が大きい間認証サーバーでのパフォーマンスドレイン (解放) です。TOTP は、効率性を向上させるために、使用するパスワードを記憶しないため、データベースの更新を行う必要はありません。欠点は、有効な期間で TOTP を再使用できることです。

8.2.2. TOTP 設定オプション

8.2.2.1. OTP ハッシュアルゴリズム

デフォルトのアルゴリズムは SHA1 です。これ以外のセキュアなオプションは SHA256 と SHA512 です。

8.2.2.2. 数字の数

OTP の長さ。短い OTP はユーザーフレンドリーで、種類が簡単で、覚えやすいものになります。OTP が長いほど、OTP が短くなるよりも安全です。

8.2.2.3. ウィンドウを見てください

サーバーがハッシュを照合しようとする間隔数。このオプションは、TOTP ジェネレーターまたは認証サーバーのクロックが非同期になると、Red Hat Single Sign-On に表示されます。デフォルト値は 1 です。たとえば、トークンの時間間隔が 30 秒の場合、デフォルト値の 1 は、90 秒のウィンドウで有効なトークンを受け入れることを意味します (時間間隔 30 秒 + 先読み 30 秒 + 後読み 30 秒)。この値を増やすたびに、有効なウィンドウが 60 秒ずつ増加します (30 秒先を見る + 30 秒後を見る)。

8.2.2.4. OTP トークン期間

サーバーがハッシュに一致する間隔(秒単位)。間隔がパスするたびに、トークンジェネレーターは TOTP を生成します。

8.2.3. HOTP 設定オプション

8.2.3.1. OTP ハッシュアルゴリズム

デフォルトのアルゴリズムは SHA1 です。これ以外のセキュアなオプションは SHA256 と SHA512 です。

8.2.3.2. 数字の数

OTP の長さ。短い OTP はユーザーフレンドリーで、種類が簡単で、覚えやすいものになります。長い OTP は、OTP を短くするより安全です。

8.2.3.3. 事前画面に移動

サーバーがハッシュを照合しようとする間隔数。このオプションは、TOTP ジェネレーターまたは認証サーバーのクロックが非同期になると、Red Hat Single Sign-On に表示されます。デフォルト値は 1 です。このオプションは、Red Hat Single Sign-On に存在し、ユーザーのカウンターがサーバーよりも進んでいる場合に対応します。

8.2.3.4. 初期カウンター

初期カウンターの値。

8.3. 認証フロー

認証フローは、認証、画面、およびアクションのコンテナー、ログイン、登録、およびその他の Red Hat Single Sign-On ワークフローのコンテナーです。すべてのフロー、アクション、およびチェックを表示するには、各フローには以下が必要です。

手順

  1. メニューで Authentication をクリックします。
  2. Flows タブをクリックします。

8.3.1. 組み込みフロー

Red Hat Single Sign-On には複数の組み込みフローがあります。これらのフローは変更できませんが、フローの要件をニーズに合わせて変更することができます。

ドロップダウンリストで、ブラウザー を選択して Browser Flow 画面を表示します。

ブラウザーのフロー

Browser Flow

ドロップダウンリストの question-mark ツールにカーソルを合わせ、フローの説明を表示します。2 つのセクションがあります。

8.3.1.1. 認証タイプ

実行する認証またはアクションの名前。認証がインデントされると、これはサブフローにあります。これは、親の動作によって実行されるか、または実行されていない可能性があります。

  1. cookie

    ユーザーが初めてログインすると、Red Hat Single Sign-On はセッションクッキーを設定します。クッキーがすでに設定されている場合、この認証タイプは成功します。Cookie プロバイダーが成功し、各フローのレベルでの実行は 代替 であるため、Red Hat Single Sign-On は他の実行を実行しません。これにより、ログインに成功します。

  2. Kerberos

    このオーセンティケーターはデフォルトで無効になっており、ブラウザーフローではスキップされます。

  3. アイデンティティープロバイダーのリダイレクター

    このアクションは、Actions > Config リンクで設定されます。アイデンティティーブローカーのために別の IdP にリダイレクトされます。

  4. フォーム

    このサブフローは 代替 としてマークされているため、Cookie 認証タイプ が渡されると実行されません。このサブフローには、実行する必要がある追加の認証タイプが含まれています。Red Hat Single Sign-On は、このサブフローの実行を読み込み、処理します。

最初の実行は、ユーザー名とパスワードのページをレンダリングする認証タイプである Username Password Form です。これは必須と識別されているため、ユーザーは有効なユーザー名とパスワードを入力する必要があります。

2 回目の実行は、Browser - Conditional OTP サブフローです。このサブフローはconditional で、ユーザー設定の実行結果 Condition - User Configured 実行に応じて実行されます。結果が true の場合、Red Hat Single Sign-On はこのサブフローの実行を読み込み、処理します。

次の実行は、Condition - User Configured 認証です。この認証は、Red Hat Single Sign-On がユーザーのフローで他の実行を設定したかどうかを確認します。Browser - Conditional OTP サブフローは、ユーザーが OTP 認証情報が設定された場合にのみ実行されます。

最後の実行は OTP Form です。Red Hat Single Sign-On は、必要 に応じて、この実行をマークします。、ユーザーが 条件付き サブフローの設定が原因で OTP 認証情報が設定された場合に限り実行されます。そうでない場合は、OTP フォームは表示されません。

8.3.1.2. 要件

アクション実行を制御するラジオボタンのセット。

8.3.1.2.1. 必須

フローで 必須 要素がすべて順次実行される必要があります。フローは、必須要素が失敗すると終了します。

8.3.1.2.2. 代替方法

フローが正常に実行されると評価するには、単一の要素のみを正常に実行する必要があります。Required flow 要素にはフローに successful というマークを付けるだけで十分であるため、Required フロー要素が含まれるフロー内の Alternative flow 要素は実行されません。

8.3.1.2.3. 無効

要素は、フローに successful というマークを付けることはできません。

8.3.1.2.4. 条件

この要件タイプはサブフローにのみ設定されます。

  • Conditional サブフローには実行が含まれます。これらの実行は論理ステートメントに評価する必要があります。
  • すべての実行が true として評価されると、Conditional サブフローは必須として動作します。
  • すべての実行が false と評価されると、Conditional サブフローは Disabled として機能します。
  • 実行を設定しない場合、Conditional サブフローは Disabled として機能します。
  • フローに実行が含まれ、フローが Conditional に設定されていない場合、Red Hat Single Sign-On は実行を評価せず、実行は機能的に Disabled と見なされます。

8.3.2. フローの作成

フローの設計時に、重要な機能およびセキュリティー上の考慮事項が適用されます。

フローを作成するには、以下を実行します。

手順

  1. メニューで Authentication をクリックします。
  2. New をクリックします。
注記

既存のフローをコピーおよび変更できます。フローを選択し、Copy をクリックし、新しいフローの名前を入力します。

新しいフローを作成する場合は、まず以下のオプションでトップレベルフローを作成する必要があります。

Alias
フローの名前。
Description
フローに設定できる説明。
Top-Level Flow Type
フローのタイプ。タイプ クライアントは、クライアント (アプリケーション) の認証にのみ使用されます。その他のケースについては、generic を選択します。

トップレベルフローの作成

Top Level Flow

Red Hat Single Sign-On がフローを作成すると、Red Hat Single Sign-On に DeleteAdd execution、および Add flow ボタンが表示されます。

空の新規フロー

New Flow

3 つの要因により、フローとサブフローの動作が決定されます。

  • フローおよびサブフローの構造。
  • フロー内での実行
  • サブフローおよび実行内で設定される要件。

リセットメールの送信から OTP の検証まで、実行にはさまざまなアクションを設定できます。Add execution ボタンで実行を追加します。Provider の横にある疑問符にカーソルを合わせ、実行の説明を確認します。

認証実行の追加

Adding an Authentication Execution

自動実行インタラクティブな実行の 2 種類の実行があります。自動実行Cookie 実行に類似し、フローのアクションを自動的に実行します。インタラクティブな実行は、入力を取得するためにフローを停止します。正常に実行されると、ステータスを success に設定します。フローが完了するには、ステータスが success の実行が少なくとも 1 つ必要です。

Add flow ボタンを使用して、サブフローを最上位のフローに追加できます。Add flow ボタンをクリックすると、Create Execution Flow ページが表示されます。このページは Create Top Level Form ページに似ています。相違点は、Flow Typegeneric(デフォルト)または form に設定できることです。form タイプは、組み込み Registration フローに似た、ユーザーのフォームを生成するサブフローを構築します。サブフローが成功するかどうかは、含まれるサブフローを含め、実行がどのように評価されるかによります。サブフローの仕組みに関する詳細は、実行要件 のセクションを参照してください。

注記

実行を追加したら、要件の値が正しいことを確認します。

フローのすべての要素には、Actions メニューに Delete オプションがあります。このアクションは、フローから要素を削除します。実行には、実行を設定するための Config メニューオプションがあります。Add execution および Add flow メニューオプションで、実行およびサブフローをサブフローに追加することもできます。

実行の順序は重要であるため、名前の横にある上下ボタンで、実行とサブフローをフロー内で上下に動かすことができます。

警告

認証フローを設定するときは、設定を適切にテストして、セットアップにセキュリティーホールが存在しないことを確認してください。さまざまなコーナーケースをテストすることが推奨されます。たとえば、認証前にユーザーのアカウントからさまざまな資格情報を削除するときに、ユーザーの認証動作をテストすることを検討してください。

たとえば、OTP フォームや WebAuthn オーセンティケーターなどの第 2 要素オーセンティケーターがフローで REQUIRED として設定されていて、ユーザーが特定のタイプのクレデンシャルを持っていない場合、ユーザーは認証自体の間に特定のクレデンシャルをセットアップできます。この状況は、認証中にユーザーがこの認証情報で認証されないことを意味します。ブラウザー認証の場合は、Password や WebAuthn Passwordless Authenticator などの一部の 1 つの要素認証情報で認証フローを設定してください。

8.3.3. パスワードなしのブラウザーログインフローの作成

フローの作成を説明するために、本セクションでは高度なブラウザーログインフローの作成について説明します。このフローの目的は、ユーザーが、WebAuthn によるパスワードなしの方法でのログインと、パスワードと OTP を使用した二要素認証を選択できるようにすることです。

手順

  1. メニューで Authentication をクリックします。
  2. Flows タブをクリックします。
  3. New をクリックします。
  4. エイリアスとして Browser Password-less を入力します。
  5. Save をクリックします。
  6. Add execution をクリックします。
  7. ドロップダウンリストから Cookie を選択します。
  8. Save をクリックします。
  9. Cookie 認証タイプの Alternative をクリックして、その要件を代替に設定します。
  10. Add execution をクリックします。
  11. ドロップダウンリストから Kerberos を選択します。
  12. Add execution をクリックします。
  13. ドロップダウンリストから Identity Provider Redirector を選択します。
  14. Save をクリックします。
  15. Identity Provider Redirector 認証タイプの Alternative をクリックして、その要件を代替に設定します。
  16. Add flow をクリックします。
  17. エイリアスとして Forms を入力します。
  18. Save をクリックします。
  19. Forms 認証タイプの Alternative をクリックして、その要件を代替に設定します。

    ブラウザーフローの共通部分

    Passwordless browser login common

  20. Forms 実行の Actions をクリックします。
  21. Add execution を選択します。
  22. ドロップダウンリストから Username Form を選択します。
  23. Save をクリックします。
  24. Username Form 認証タイプの Required をクリックして、その要件を必須に設定します。

この段階では、フォームにはユーザー名が必要ですが、パスワードは必要ありません。セキュリティーリスクを回避するために、パスワード認証を有効にする必要があります。

  1. Forms サブフローの Actions をクリックします。
  2. Add flow をクリックします。
  3. エイリアスとして Authentication を入力します。
  4. Save をクリックします。
  5. Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
  6. Authentication サブフローの Actions をクリックします。
  7. Add execution をクリックします。
  8. ドロップダウンリストから Webauthn Passwordless Authenticator を選択します。
  9. Save をクリックします。
  10. Webauthn Passwordless Authenticator 認証タイプの Alternative をクリックして、その要件を代替に設定します。
  11. Authentication サブフローの Actions をクリックします。
  12. Add flow をクリックします。
  13. エイリアスとして Password with OTP を入力します。
  14. Save をクリックします。
  15. Password with OTP 認証タイプの Alternative をクリックして、その要件を代替に設定します。
  16. Password with OTP サブフローの Actions をクリックします。
  17. Add execution をクリックします。
  18. ドロップダウンリストから Password Form を選択します。
  19. Save をクリックします。
  20. Password Form 認証タイプの Required をクリックして、その要件を必須に設定します。
  21. Password with OTP サブフローの Actions をクリックします。
  22. Add execution をクリックします。
  23. ドロップダウンリストから OTP Form を選択します。
  24. Save をクリックします。
  25. OTP Form 認証タイプの Required をクリックして、その要件を必須に設定します。

最後に、バインディングを変更します。

  1. Bindings タブをクリックします。
  2. Browser Flow ドロップダウンリストをクリックします。
  3. ドロップダウンリストから Browser Password-less を選択します。
  4. Save をクリックします。

パスワードなしのブラウザーログイン

Passwordless browser login

ユーザー名を入力すると、フローは以下のように機能します。

ユーザーの WebAuthn パスワードレス認証情報が記録されている場合は、これらの認証情報を使用して直接ログインできます。これはパスワードなしのログインです。WebAuthn Passwordless 実行および Password with OTP フローが Alternative に設定されているため、ユーザーは Password with OTP を選択することもできます。Required に設定されている場合は、ユーザーは WebAuthn、パスワード、および OTP を入力する必要があります。

ユーザーが WebAuthn passwordless 認証で Try another wayのリンクを選択する場合、ユーザーは PasswordSecurity Key(WebAuthn パスワードレス)のいずれかを選択できます。パスワードを選択すると、ユーザーは続行して、割り当てられた OTP でログインする必要があります。ユーザーに WebAuthn 認証情報がない場合は、ユーザーはパスワードを入力し、続いて OTP を入力する必要があります。ユーザーに OTP 認証情報がない場合は、記録することが要求されます。

注記

WebAuthn Passwordless 実行は Required ではなく Alternative に設定されているため、このフローはユーザーに WebAuthn 認証情報を登録するように要求しません。ユーザーに Webauthn 認証情報を設定するには、管理者がユーザーに必要なアクションを追加する必要があります。これを行うには、以下を実行します。

  1. レルムで Webauthn Register Passwordless で必要なアクションを有効にします (WebAuthn のドキュメントを参照)。
  2. ユーザーの Credentials 管理メニューの Credential Reset 部分を使用して、必要なアクションを設定します。

このような高度なフローを作成すると、副次的な影響が生じる可能性があります。たとえば、ユーザーのパスワードをリセットできるようにする場合は、パスワードフォームからアクセスが可能になります。デフォルトの Reset Credentials フローで、ユーザーはユーザー名を入力する必要があります。ユーザーは Browser Password-less フローで先にユーザー名を入力しているため、Red Hat Single Sign-On ではこの操作は必要なく、ユーザーエクスペリエンスとしては最適ではありません。この問題を修正するには、以下を行います。

  • Reset Credentials フローをコピーします。たとえば、その名前を Reset Credentials for password-less に設定します。
  • Choose user 実行の Actions メニューで Delete を選択します。
  • Bindings メニューで、認証情報のリセットフローを Reset Credentials から Reset Credentials for password-less に変更します。

8.3.4. ステップアップメカニズムを使用したブラウザーログインフローの作成

本セクションでは、ステップアップメカニズムを使用して高度なブラウザーログインフローを作成する方法を説明します。ステップ認証の目的は、ユーザーの特定の認証レベルに基づいてクライアントまたはリソースへのアクセスを許可することです。

手順

  1. メニューで Authentication をクリックします。
  2. Flows タブをクリックします。
  3. New をクリックします。
  4. Browser Incl Step up Mechanism をエイリアスとして入力します。
  5. Save をクリックします。
  6. Add execution をクリックします。
  7. アイテムリストから Cookieを選択します。
  8. Save をクリックします。
  9. Cookie 認証タイプの Alternative をクリックして、その要件を代替に設定します。
  10. Add flow をクリックします。
  11. Auth Flow をエイリアスとして入力します。
  12. Save をクリックします。
  13. Auth Flow 認証タイプの Alternative をクリックして、その要件を代替に設定します。

最初の認証レベルのフローを設定します。

  1. Auth FlowActions をクリックします。
  2. Add flow をクリックします。
  3. 1st Condition Flow をエイリアスとして入力します。
  4. Save をクリックします。
  5. 1st Condition Flow 認証タイプの Conditional をクリックし、その要件を条件に設定します。
  6. 1st Condition FlowActions をクリックします。
  7. Add execution をクリックします。
  8. 項目 リストから Conditional - Level Of Authentication を選択します。
  9. Save をクリックします。
  10. Conditional - Level Of Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
  11. Conditional - Level Of AuthenticationActions をクリックします。
  12. Config をクリックします。
  13. Level 1 をエイリアスとして入力します。
  14. レベル認証 (LoA) に 1 と入力します。
  15. Max Age を 36000 に設定します。この値は秒単位であり、10 時間に相当します。これは、レルムで設定されているデフォルトの SSO Session Max タイムアウトです。その結果、ユーザーがこのレベルで認証される場合、後続の SSO ログインはこのレベルを再利用でき、ユーザーセッションが終了するまでユーザーはこのレベルで認証する必要はありません (デフォルトでは 10 時間)。
  16. 保存 をクリックします。

    最初の認証レベルの条件を設定します。

    authentication step up condition 1

  17. 1st Condition FlowActions をクリックします。
  18. Add execution をクリックします。
  19. アイテムリストから Usernmae Password Form を選択します。
  20. Save をクリックします。
  21. Username Password Form 認証タイプの Required をクリックして、その要件を必須に設定します。

これで、2 つ目の認証レベルのフローが設定されます。

  1. Auth FlowActions をクリックします。
  2. Add flow をクリックします。
  3. 2nd Condition Flow をエイリアスとして入力します。
  4. Save をクリックします。
  5. 2st Condition Flow 認証タイプの Conditional をクリックし、その要件を条件に設定します。
  6. 2st Condition FlowActions をクリックします。
  7. Add execution をクリックします。
  8. 項目 リストから Conditional - Level Of Authentication を選択します。
  9. Save をクリックします。
  10. Conditional - Level Of Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
  11. Conditional - Level Of AuthenticationActions をクリックします。
  12. Config をクリックします。
  13. Level 2 をエイリアスとして入力します。
  14. 認証レベル (LoA) に 2 と入力します。
  15. Max Age を 0 に設定します。その結果、ユーザーが認証する場合、このレベルは現在の認証に対してのみ有効ですが、後続の SSO 認証に対しては有効ではありません。したがって、このレベルが要求された場合、ユーザーは常にこのレベルで再度認証する必要があります。
  16. 保存 をクリックします。

    2 つ目の認証レベルの条件を設定する

    authentication step up condition 2

  17. 2st Condition FlowActions をクリックします。
  18. Add execution をクリックします。
  19. アイテムリストから OTP Form を選択します。
  20. Save をクリックします。
  21. OTP Form 認証タイプの Required をクリックして、その要件を必須に設定します。

最後に、バインディングを変更します。

  1. Bindings タブをクリックします。
  2. Browser Flow item リストをクリックします。
  3. 項目リストから Browser Incl Step up Mechanism を選択します。
  4. Save をクリックします。

ステップアップメカニズムによるブラウザーログイン

authentication step up flow

特定の認証レベルを要求します。

ステップアップメカニズムを使用するには、認証リクエストに要求された認証レベル (LoA) を指定します。claimsパラメーターは、この目的で使用されます。

https://{DOMAIN}/auth/realms/{REALMNAME}/protocol/openid-connect/auth?client_id={CLIENT-ID}&redirect_uri={REDIRECT-URI}&scope=openid&response_type=code&response_mode=query&nonce=exg16fxdjcu&claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22gold%22%5D%7D%7D%7D

claims パラメーターは JSON 表現で指定されます。

claims= {
            "id_token": {
                "acr": {
                    "essential": true,
                    "values": ["gold"]
                }
            }
        }

Red Hat Single Sign-On JavaScript アダプターは、この JSON を簡単に構築し、ログイン要求で送信することをサポートしています。詳細は、Javascript アダプターのドキュメント を参照してください。

また、claims パラメーターの代わりに単純なパラメーター acr_values を使用して、特定のレベルを必須ではないものとして要求することもできます。これは OIDC 仕様で説明されています。

特定のクライアントのデフォルトレベルを設定することもできます。これは、acr_values パラメーターまたは acr 要求のある claims パラメーター要求が存在しない場合に使用されます。詳細は、Client ACR configuration を参照してください。

注記

acr_values を数値ではなくテキスト (gold など) として要求するには、ACR と LoA の間のマッピングを設定します。レルムレベル (推奨) またはクライアントレベルで設定できます。設定については、ACR から LoA へのマッピングを 参照してください。

詳細は、公式の OIDC 仕様 を参照してください。

フローロジック

以前に設定された認証フローのロジックは次のとおりです。
クライアントが高い認証レベル、つまり認証レベル 2 (LoA 2) を要求した場合、ユーザーは完全な 2 要素認証 (ユーザー名/パスワード + OTP) を実行する必要があります。ただし、ユーザーが Keycloak で既にセッションを持っていて、それがユーザー名とパスワード (LoA 1) でログインしている場合、ユーザーは 2 番目の認証要素 (OTP) のみを要求されます。

条件の Max Age 時間オプションは、後続の認証レベルが有効である期間 (秒数) を決定します。この設定は、ユーザーが後続の認証中に認証要素を再度提示するように求められるかどうかを決定するのに役立ちます。特定のレベル X が claims または acr_values パラメーターによって要求され、ユーザーがすでにレベル X で認証されているが、有効期限が切れている場合 (たとえば、最大年齢が 300 に設定され、ユーザーが 310 秒前に認証された場合)、ユーザーは再認証を求められます。特定のレベルで再度認証します。ただし、レベルが期限切れでない場合、ユーザーは自動的にそのレベルで認証されていると見なされます。

Max Age を値 0 で使用すると、その特定のレベルはこの単一認証でのみ有効です。そのため、そのレベルを要求するすべての再認証では、そのレベルで再度認証する必要があります。これは、アプリケーションでより高いセキュリティーを必要とし (支払いの送信など)、常に特定のレベルでの認証を必要とする操作に役立ちます。

警告

ログイン要求がクライアントからユーザーのブラウザーを介して Red Hat Single Sign-On に送信されるときに、claimacr_values などのパラメーターが URL 内のユーザーによって変更される可能性があることに注意してください。この状況は、クライアントが PAR (プッシュされた承認要求)、要求オブジェクト、またはユーザーが URL のパラメーターを書き換えることを妨げるその他のメカニズムを使用する場合に軽減できます。そのため、認証後に、トークンの acr が予想されるレベルに対応するように ID トークンを確認することが推奨されます。

パラメーターによって明示的なレベルが要求されていない場合、Red Hat Single Sign-On では、前の例のユーザー名/パスワードなど、認証フローで最初に見つかった LoA 条件での認証が必要になります。ユーザーがそのレベルですでに認証され、そのレベルの有効期限が切れると、ユーザーは再認証する必要はありませんが、トークンの acr の値は 0 になります。この結果は、OIDC Core 1.0 仕様のセクション 2 で説明されているように、long-lived browser cookie のみに基づく認証と見なされます。

注記

管理者が複数のフローを指定し、異なる LoA レベルをそれぞれに設定し、フローを別のクライアントに割り当てると、競合状況が発生する可能性があります。ただし、ルールは常に同じです。ユーザーに特定のレベルがある場合は、クライアントに接続するためにそのレベルのみが必要になります。LoA が一貫していることを確認するのは管理者次第です。

シナリオ例

  1. Max Age は、レベル 1 の状態で 300 秒として設定されています。
  2. ログイン要求は、acr を要求せずに送信されます。レベル 1 が使用され、ユーザーはユーザー名とパスワードで認証する必要があります。トークンには acr=1 があります。
  3. 別のログイン要求は 100 秒後に送信されます。SSO によりユーザーが自動的に認証され、トークンは acr=1 を返します。
  4. さらに 201 秒 (ポイント 2 での認証から 301 秒) 後に別のログイン要求が送信されます。ユーザーは SSO により自動的に認証されますが、レベル 1 が期限切れと見なされるため、トークンは acr=0 を返します。
  5. 別のログイン要求が送信されますが、これで、claims パラメーターでレベル 1 の ACR が明示的に要求されます。ユーザーはユーザー名/パスワードで再認証するように求められ、その後 acr=1 がトークンで返されます。

トークンの ACR クレーム

ACR 要求は、acr クライアントスコープで定義された acr loa level のプロトコルマッパーによってトークンに追加されます。このクライアントスコープはレルムのデフォルトのクライアントスコープであるため、レルム内に新しく作成されたすべてのクライアントに追加されます。

トークン内で acr クレームが必要ない場合、またはトークンを追加するためのカスタムロジックが必要な場合は、クライアントからクライアントスコープを削除できます。

ログイン要求が acressential の要求として要求する claims パラメーターを使用して要求を開始すると、Red Hat Single Sign-On は常に指定されたレベルの 1 つを返すことに注意してください。指定されたレベルの 1 つを返すことができない場合 (たとえば、要求されたレベルが不明であるか、認証フローで設定された条件よりも大きい場合)、Red Hat Single Sign-On はエラーを出力します。

ユーザーセッションの制限

ユーザーが持つことができるセッション数の制限を設定できます。セッションは、レルムごとまたはクライアントごとに制限できます。

フローにセッション制限を追加するには、次の手順を実行します。

  1. フローの 実行の追加 をクリックします。
  2. 項目 リストから User Session Count Limiter を選択します。
  3. Save をクリックします。
  4. ユーザーセッションカウントリミッター 認証タイプの 必須 をクリックして、要件を必須に設定します。
  5. ユーザーセッション数制限アクション をクリックします。
  6. Config をクリックします。
  7. この設定のエイリアスを入力します。
  8. このレルムでユーザーが持つことができるセッションの最大数を入力します。0 の値を使用すると、このチェックは無効になります。
  9. クライアントにユーザーが持つことができるセッションの最大数を入力します。0 の値を使用すると、このチェックは無効になります。
  10. 制限に達するとユーザーがセッションを作成しようとすると必要な動作を選択します。利用可能な動作は以下のとおりです。

    Deny new session - when a new session is requested and the session limit is reached, no new sessions can be created.
    Terminate oldest session - when a new session is requested and the session limit has been reached, the oldest session will be removed and the new session created.
  11. 必要に応じて、制限に達すると表示されるカスタムエラーメッセージを追加します。

ユーザーセッション制限は、バインドされた Browser FlowDirect Grant FlowReset Credentials、および Post Broker Login Flow に追加される必要があることに注意してください。現在、管理者は異なる設定間で整合性を維持します。

また、CIBA ではユーザーセッション制限機能は利用できないことに注意してください。

8.4. Kerberos

Red Hat Single Sign-On は、Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) プロトコルを使用した Kerberos チケットによるログインをサポートします。ユーザーがセッションを認証した後、SPNEGO は Web ブラウザーを介して透過的に認証します。Web 以外のケースや、ログイン時にチケットが利用できない場合、Red Hat Single Sign-On は Kerberos のユーザー名およびパスワードを使用したログインをサポートします。

Web 認証の一般的なユースケースは以下のとおりです。

  1. ユーザーはデスクトップにログインしています。
  2. ユーザーは、ブラウザーで Red Hat Single Sign-On によってセキュリティーが保護された Web アプリケーションにアクセスします。
  3. アプリケーションは Red Hat Single Sign-On ログインにリダイレクトされます。
  4. Red Hat Single Sign-On は、ステータス 401 および HTTP ヘッダー WWW-Authenticate: Negotiate の HTML ログイン画面をレンダリングします。
  5. ブラウザーにデスクトップログインからの Kerberos チケットがある場合、ブラウザーはヘッダー Authorization: Negotiate 'spnego-token' で、デスクトップサインオン情報を Red Hat Single Sign-On に転送します。それ以外の場合は、標準のログイン画面が表示され、ユーザーはログイン認証情報を入力します。
  6. Red Hat Single Sign-On は、ブラウザーからのトークンを検証し、ユーザーを認証します。
  7. LDAPFederationProvider と Kerberos 認証サポートを使用している場合、Red Hat Single Sign-On は LDAP からユーザーデータをプロビジョニングします。KerberosFederationProvider を使用する場合、Red Hat Single Sign-On では、ユーザーはプロファイルを更新でき、ログインデータをプレフィルします。
  8. Red Hat Single Sign-On はアプリケーションに戻ります。Red Hat Single Sign-On とアプリケーションは、OpenID Connect または SAML メッセージを介して通信します。Red Hat Single Sign-On は、Kerberos/SPNEGO ログインに対するブローカーとして機能します。したがって、Kerberos で認証する Red Hat Single Sign-On は、アプリケーションからは認識されません。

Kerberos 認証を設定するには、以下の手順を実行します。

  1. Kerberos サーバー(KDC)のセットアップと設定。
  2. Red Hat Single Sign-On サーバーのセットアップと設定。
  3. クライアントマシンのセットアップと設定。

8.4.1. Kerberos サーバーの設定

Kerberos サーバーを設定する手順は、オペレーティングシステム(OS)および Kerberos ベンダーによって異なります。Kerberos サーバーのセットアップおよび設定方法は、Windows Active Directory、MIT Kerberos、および OS のドキュメントを参照してください。

セットアップ時に、以下の手順を実行します。

  1. Kerberos データベースにユーザープリンシパルを追加します。Kerberos と LDAP を統合することも可能です。つまり、ユーザーアカウントが LDAP サーバーからプロビジョニングされます。
  2. HTTP サービスのサービスプリンシパルを追加します。たとえば、Red Hat Single Sign-On サーバーが www.mydomain.org で実行している場合は、サービスプリンシパル HTTP/www.mydomain.org@<kerberos realm> を追加します。

    MIT Kerberos では、「kadmin」セッションを実行します。MIT Kerberos を使用するマシンで、以下のコマンドを使用できます。

sudo kadmin.local

次に、以下のようなコマンドを使用して、HTTP プリンシパルを追加し、そのキーを keytab ファイルにエクスポートします。

addprinc -randkey HTTP/www.mydomain.org@MYDOMAIN.ORG
ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG

Red Hat Single Sign-On が稼働しているホストで keytab ファイル /tmp/http.keytab にアクセスできる必要があります。

8.4.2. Red Hat Single Sign-On サーバーの設定および設定

Kerberos クライアントをマシンにインストールします。

手順

  1. Kerberos クライアントをインストールします。マシンが Fedora、Ubuntu、または RHEL を実行している場合は、Kerberos クライアントおよびその他のユーティリティーが含まれる freeipa-client パッケージをインストールします。
  2. Kerberos クライアントを設定します(Linux では、構成設定は /etc/krb5.conf ファイルにあります)。

    Kerberos レルムを設定に追加し、サーバー稼働している HTTP ドメインを設定します。

    たとえば、MYDOMAIN.ORG レルムの場合は、以下のように domain_realm セクションを設定できます。

    [domain_realm]
      .mydomain.org = MYDOMAIN.ORG
      mydomain.org = MYDOMAIN.ORG
  3. HTTP プリンシパルを持つ keytab ファイルをエクスポートし、Red Hat Single Sign-On サーバーを実行するプロセスがファイルにアクセスできるようにします。本番環境では、このプロセスだけがこのファイルを読み取れるようにします。

    上記の MIT Kerberos の例では、キータブを /tmp/http.keytab ファイルにエクスポートしました。Key Distribution Centre (KDC) および Red Hat Single Sign-On が同じホストで実行している場合は、ファイルがすでに利用可能です。

8.4.2.1. SPNEGO 処理の有効化

デフォルトでは、Red Hat Single Sign-On は SPNEGO プロトコルのサポートを無効にしています。これを有効にするには、ブラウザーフロー に移動し、Kerberos を有効にします。

ブラウザーのフロー

Browser Flow

Kerberos 要件を disabled から alternative(Kerberos は任意)または required(ブラウザーは Kerberos を有効にする必要があります)に設定します。SPNEGO または Kerberos と連携するようにブラウザーを設定していない場合には、Red Hat Single Sign-On は通常のログイン画面にフォールバックします。

8.4.2.2. Kerberos ユーザーストレージフェデレーションプロバイダーの設定

User Storage Federation を使用して、Red Hat Single Sign-On が Kerberos チケットを解釈する方法を設定する必要があります。Kerberos 認証のサポートには、2 つの異なるフェデレーションプロバイダーがあります。

LDAP サーバーがサポートする Kerberos で認証するには、LDAP Federation Provider を設定します。

手順

  1. LDAP プロバイダーの設定ページに移動します。

    Ldap kerberos の統合

    LDAP Kerberos Integration

  2. Allow Kerberos authenticationON に切り替えます。

Allow Kerberos authentication により、Red Hat Single Sign-On は Kerberos プリンシパルアクセスユーザー情報を使用するため、情報を Red Hat Single Sign-On 環境にインポートできます。

LDAP サーバーが Kerberos ソリューションをサポートしていない場合は、Kerberos ユーザーストレージフェデレーションプロバイダーを使用します。

手順

  1. メニューの User Federation をクリックします。
  2. Add provider 選択ボックスから Kerberos を選択します。

    Kerberos ユーザーストレージプロバイダー

    Kerberos User Storage Provider

Kerberos プロバイダーは、簡単なプリンシパル情報のためにKerberos チケットを解析し、情報をローカルの Red Hat Single Sign-On データベースにインポートします。ユーザー名、姓、電子メールなどのユーザープロファイル情報はプロビジョニングされません。

8.4.3. クライアントマシンの設定および設定

クライアントマシンには Kerberos クライアントが必要であり、上記 のように krb5.conf を設定する必要があります。クライアントマシンは、ブラウザーの SPNEGO ログインサポートも有効にする必要があります。Firefox ブラウザーを使用している場合は、「configuring Firefox for Kerberos」を参照してください。

.mydomain.org URI は network.negotiate-auth.trusted-uris 設定オプションになければなりません。

Windows ドメインでは、クライアントは設定を調整する必要はありません。Internet Explorer および Edge は、すでに SPNEGO 認証に参加できます。

8.4.4. 認証情報の委譲

Kerberos は認証情報の委譲をサポートします。アプリケーションは Kerberos チケットを再利用してKerberos でセキュリティーが保護された他のサービスと対話できるように、チケットへのアクセスが必要になる場合があります。Red Hat Single Sign-On サーバーが SPNEGO プロトコルを処理するため、OpenID Connect トークン要求または SAML アサーション属性内のアプリケーションに GSS 認証情報を反映させる必要があります。Red Hat Single Sign-On は、これを Red Hat Single Sign-On サーバーからアプリケーションに送信します。この要求をトークンまたはアサーションに挿入するには、各アプリケーションはビルトインプロトコルマッパーgss delegation credential を有効にする必要があります。このマッパーは、アプリケーションのクライアントページの Mappers タブで利用できます。詳細は、「プロトコルマッパー」の章を参照してください。

アプリケーションは、Red Hat Single Sign-On から受信する要求を使用して他のサービスに対して GSS 呼び出しを行う前に、その要求をデシリアライズする必要があります。アクセストークンから GSSCredential オブジェクトに認証情報をデシリアライズする場合は、GSSManager.createContext メソッドに渡されるこのクレデンシャルで GSSContext を作成します。以下に例を示します。

// Obtain accessToken in your application.
KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal();
AccessToken accessToken = keycloakPrincipal.getKeycloakSecurityContext().getToken();

// Retrieve Kerberos credential from accessToken and deserialize it
String serializedGssCredential = (String) accessToken.getOtherClaims().
    get(org.keycloak.common.constants.KerberosConstants.GSS_DELEGATION_CREDENTIAL);

GSSCredential deserializedGssCredential = org.keycloak.common.util.KerberosSerializationUtils.
    deserializeCredential(serializedGssCredential);

// Create GSSContext to call other Kerberos-secured services
GSSContext context = gssManager.createContext(serviceName, krb5Oid,
    deserializedGssCredential, GSSContext.DEFAULT_LIFETIME);
注記

krb5.conf ファイルで 転送可能な Kerberos チケットを設定し、委譲された認証情報のサポートをブラウザーに追加します。

警告

認証情報の委譲はセキュリティーに影響するため、必要かつ HTTPS を使用する場合にのみ使用してください。詳細と例については、この記事 を参照してください。

8.4.5. レルム間の信頼

Kerberos プロトコルでは、レルム は Kerberos プリンシパルのセットです。これらのプリンシパルの定義は Kerberos データベース(通常は LDAP サーバー)に存在します。

Kerberos プロトコルは、レルム間の信頼を許可します。たとえば、2 つのKerberos レルム A および B が存在する場合は、レルム間の信頼により、レルム A のユーザーがレルム B のリソースにアクセスできるようになります。レルム B がレルム A を信頼します。

Kerberos レルム間の信頼

kerberos trust basic

Red Hat Single Sign-On サーバーは、レルム間の信頼をサポートします。これを実装するには、以下を実行します。

  • レルム間の信頼用に Kerberos サーバーを設定します。この手順の実装は、Kerberos サーバーの実装によって異なります。この手順は、Kerberos プリンシパル krbtgt/B@A をレルム A および B の Kerberos データベースに追加するために必要です。このプリンシパルは両方の Kerberos レルムで同じキーを持つ必要があります。プリンシパルは、両方のレルムで同じパスワード、キーバージョン番号、および暗号を持つ必要があります。詳細は、Kerberos サーバーのドキュメントを参照してください。
注記

レルム間の信頼は、デフォルトで一方向です。レルム A とレルム B 間の双方向の信頼のために、プリンシパル krbtgt/A@B を両方の Kerberos データベースに追加する必要があります。ただし、信頼はデフォルトで推移的です。レルム B がレルム A を信頼し、レルム C がレルム B を信頼する場合、レルム C は、プリンシパル krbtgt/C@A なしでレルム A を信頼します。クライアントが信頼パスを見つけることができるように、Kerberos クライアント側で追加の設定(例:capaths)が必要になる場合があります。詳細は、Kerberos のドキュメントを参照してください。

  • Red Hat Single Sign-On サーバーの設定

    • Kerberos がサポートされる LDAP ストレージプロバイダーを使用する場合は、レルム B のサーバープリンシパルを設定する必要があります(この例ではHTTP/mydomain.com@B)。Red Hat Single Sign-On は SPNEGO フローを実行し、ユーザーを見つける必要があるため、レルム A からのユーザーが Red Hat Single Sign-On に対して正常に認証されるためには、LDAPサーバーはレルム A からユーザーを見つける必要があります。

たとえば、Kerberos プリンシパルユーザー john@A は、uid=john,ou=People,dc=example,dc=com などの LDAP DN の下にある LDAP で利用できるようにする必要があります。レルム A および B からのユーザーを認証する場合は、LDAP がレルム A と B 両方からのユーザーを見つけられるようにします。

  • Kerberos ユーザーストレージプロバイダー(通常は LDAP 統合のない Kerberos)を使用する場合は、サーバープリンシパルを HTTP/mydomain.com@B に設定し、Kerberos レルム A および B からのユーザーを認証できる必要があります。
警告

Kerberos ユーザーストレージプロバイダーを使用する場合は、Kerberos レルム間でのユーザーの競合は許されません。競合するユーザーが存在する場合は、Red Hat Single Sign-On はそれらを同じユーザーにマッピングします。

8.4.6. トラブルシューティング

問題がある場合は、追加のロギングを有効にして問題をデバッグしてください。

  • Kerberos または LDAP フェデレーションプロバイダーについて、管理コンソールで Debug フラグを有効にします。
  • カテゴリー org.keycloak に対して TRACE ロギングを有効にして、サーバーログで詳細情報を受け取る
  • システムプロパティー -Dsun.security.krb5.debug=true および -Dsun.security.spnego.debug=true を追加します。

8.5. X.509 クライアント証明書ユーザー認証

相互 SSL 認証を使用するようにサーバーを設定した場合、Red Hat Single Sign-On は、X.509 クライアント証明書を使用したログインをサポートします。

通常のワークフロー:

  • クライアントは SSL/TLS チャンネルで認証リクエストを送信します。
  • SSL/TLS ハンドシェイクの間、サーバーとクライアントは x.509/v3 証明書を交換します。
  • コンテナー (JBoss EAP) は、証明書 PKIX パスと証明書の有効期限を検証します。
  • X.509 クライアント証明書オーセンティケーターは、以下の方法を使用してクライアント証明書を検証します。

    • CRL または CRL Distribution Points を使用して、証明書失効ステータスを確認します。
    • OCSP (Online Certificate Status Protocol) を使用して、証明書失効ステータスを確認します。
    • 証明書の鍵が予想される鍵と一致するかどうかを確認します。
    • 証明書の拡張鍵が、想定された拡張鍵と一致するかどうかを検証します。
  • これらのチェックのいずれかが失敗すると、x.509 認証は失敗します。それ以外の場合は、オーセンティケーターは証明書のアイデンティティーを抽出し、これを既存ユーザーにマッピングします。

証明書が既存のユーザーにマッピングされると、認証フローに応じてさまざまな動作が行われます。

  • Browser Flowでは、サーバーはユーザーに対してアイデンティティーを確認するか、ユーザー名とパスワードを使用してサインインするよう要求します。
  • Direct Grant Flow では、サーバーはユーザーにサインインします。
重要

証明書 PKIX パスを検証するのは Web コンテナーの役割であることに注意してください。Red Hat Single Sign-On 側の X.509 オーセンティケーターは、証明書の有効期限、証明書失効ステータス、およびキーの使用を確認する追加のサポートのみを提供します。リバースプロキシーの背後にデプロイされた Red Hat Single Sign-On を使用している場合は、リバースプロキシーが PKIX パスを検証するように設定されていることを確認します。リバースプロキシーを使用せず、ユーザーが JBoss EAP に直接アクセスする場合は、以下のように PKIX パスが設定されている限り、JBoss EAPが PKIX パスが検証された状態を維持するので問題ありません。

8.5.1. 機能

サポートされる証明書アイデンティティーソース:

  • 正規表現を使用した SubjectDN の一致
  • X500 サブジェクトの email 属性
  • Subject Alternative Name Extension からの X500 サブジェクトのemail (RFC822Name General Name)
  • サブジェクトの別名エクステンションの X500 サブジェクトの他の名前。通常、この他の名前は User Principal Name (UPN) です。
  • X500 サブジェクトのコモンネーム属性
  • 正規表現を使用した IssuerDN の一致
  • 証明書のシリアル番号
  • Certificate Serial Number および IssuerDN
  • SHA-256 証明書サムプリント
  • PEM 形式の完全な証明書

8.5.1.1. 正規表現

Red Hat Single Sign-On は、正規表現をフィルターとして使用して、サブジェクト DN または発行者 DN から証明書のアイデンティティーを抽出します。たとえば、以下の正規表現は email 属性とマッチします。

emailAddress=(.*?)(?:,|$)

正規表現のフィルターは、Identity Source が、Match SubjectDN using regular expression または Match IssuerDN using regular expression のいずれかに設定されている場合にのみ適用されます。

8.5.1.1.1. 既存のユーザーへの証明書 ID のマッピング

証明書アイデンティティーマッピングは、抽出したユーザー ID を、既存のユーザーのユーザー名、メール、または値が証明書 ID とマッチするカスタム属性にマッピングできます。たとえば、Identity sourceSubject’s email に設定するか、User mapping methodUsername or email に設定すると、X.509 クライアント証明書オーセンティケーターは、ユーザー名または電子メールで既存のユーザーを検索するときに、証明書の Subject DN の email 属性を検索条件として使用します。

重要
  • レルム設定で Login with email を無効にすると、同じルールが証明書認証に適用されます。ユーザーは email 属性を使用してログインできません。
  • Certificate Serial Number and IssuerDN を ID ソースとして使用するには、シリアル番号と IssuerDN に 2 つのカスタム属性が必要です。
  • SHA-256 Certificate thumbprint は、SHA-256 証明書のサムプリントの小文字の 16 進数表記です。
  • ID ソースとしての Full certificate in PEM format の使用は、LDAP などの外部フェデレーションソースにマッピングされたカスタム属性に限定されます。Red Hat Single Sign-On は、長さの制限によりデータベースに証明書を保存できません。そのため、LDAP の場合は、Always Read Value From LDAP を有効にする必要があります。
8.5.1.1.2. 拡張証明書の検証
  • CRL を使用した失効ステータスの確認。
  • CRL/分散ポイントを使用した失効ステータスの確認。
  • OCSP/Responder URI を使用した失効ステータスの確認。
  • 証明書 KeyUsage の検証。
  • 証明書 ExtendedKeyUsage の検証。

8.5.2. X.509 クライアント証明書ユーザー認証の有効化

ここでは、JBoss EAP/Undertow および Red Hat Single Sign-On Server を設定して、X.509 クライアント証明書認証を有効にする方法を説明します。

8.5.2.1. JBoss EAP での相互 SSL の有効化

JBoss EAP で SSL を有効にする手順は、「Enable SSL」を参照してください。

  • RHSSO_HOME/standalone/configuration/standalone.xml を開き、新しいレルムを追加します。
<security-realms>
    <security-realm name="ssl-realm">
        <server-identities>
            <ssl>
                <keystore path="servercert.jks"
                          relative-to="jboss.server.config.dir"
                          keystore-password="servercert password"/>
            </ssl>
        </server-identities>
        <authentication>
            <truststore path="truststore.jks"
                        relative-to="jboss.server.config.dir"
                        keystore-password="truststore password"/>
        </authentication>
    </security-realm>
</security-realms>
ssl/keystore
ssl 要素には、JKS キーストアからサーバーの公開鍵ペアを読み込むための詳細が含まれる keystore 要素が含まれます。
ssl/keystore/path
JKS キーストアへのパス。
ssl/keystore/relative-to
キーストアパスの起点となるパス。
ssl/keystore/keystore-password
キーストアを開くためのパスワード。
ssl/keystore/alias (オプション)
キーストアのエントリーのエイリアス。キーストアに複数のエントリーが含まれる場合に設定します。
ssl/keystore/key-password (オプション)
秘密のキーパスワード (キーストアパスワードと異なる場合)。
authentication/truststore
トラストストアをロードして、インバウンド/ルーティング接続のリモート側に表示される証明書を検証する方法を定義します。通常、トラストストアには信頼される CA 証明書の集合が含まれます。
authentication/truststore/path
信頼される認証局の証明書が含まれる JKS キーストアへのパス。
authentication/truststore/relative-to
トラストストアパスの起点となるパス。
authentication/truststore/keystore-password
トラストストアを開くパスワード。

8.5.2.2. HTTPS リスナーの有効化

WildFly で HTTPS を有効にする方法については、「HTTPS Listener」を参照してください。

  • <https-listener> 要素を追加します。
<subsystem xmlns="urn:jboss:domain:undertow:12.0">
	....
    <server name="default-server">
	    <https-listener name="default"
                        socket-binding="https"
                        security-realm="ssl-realm"
                        verify-client="REQUESTED"/>
    </server>
</subsystem>
https-listener/security-realm
この値は、前のセクションのレルムの名前に一致する必要があります。
https-listener/verify-client
REQUESTED に設定した場合、サーバーは必要に応じてクライアント証明書を要求します。REQUIRED に設定すると、クライアント証明書が提供されていない場合、サーバーは受信接続を拒否します。

8.5.3. ブラウザーフローへの X.509 クライアント証明書認証の追加

  1. メニューで Authentication をクリックします。
  2. 「Browser」フローをクリックします。
  3. Copy をクリックして、ビルトインの「Browser」フローのコピーを作成します。
  4. コピーの名前を入力します。
  5. OK をクリックします。
  6. Add policy ドロップダウンボックスでコピーをクリックします。
  7. Add execution をクリックします。
  8. 「X509/Validate Username Form」をクリックします。
  9. Save をクリックします。

    X509 実行

    X509 Execution

  10. 上下の矢印ボタンをクリックして、「Browser Forms」実行の上に「X509/Validate Username Form」を移動します。
  11. 要件を「ALTERNATIVE」に設定します。

    X509 ブラウザーフロー

    X509 Browser Flow

  12. Bindings タブをクリックします。
  13. Browser Flow ドロップダウンリストをクリックします。
  14. ドロップダウンリストからブラウザーフローのコピーをクリックします。
  15. Save をクリックします。

    X509 ブラウザーフローバインディング

    X509 Browser Flow Bindings

8.5.4. X.509 クライアント証明書認証の設定

X509 設定

X509 Configuration

User Identity Source
クライアント証明書からユーザーアイデンティティーを抽出する方法を定義します。
Canonical DN representation enabled
正規の形式を使用して識別名を判断するかどうかを定義します。公式の Java API ドキュメント で形式が説明されています。このオプションは、2 つのユーザーアイデンティティーソース Match SubjectDN using regular expression および Match IssuerDN using regular expression にのみ影響します。新しい Red Hat Single Sign-On インスタンスをセットアップする際に、このオプションを有効にします。既存の Red Hat Single Sign-On インスタンスとの後方互換性を維持するには、このオプションを無効にします。
Enable Serial Number hexadecimal representation
シリアル番号を 16 進数で表します。符号ビットに 1 が設定されているシリアル番号は、00 オクテットを左に追加する必要があります。たとえば、10 進値が161のシリアル番号、または 16 進表現のa1は、RFC5280 に従って00a1としてエンコードされます。詳細は、RFC5280, appendix-B を参照してください。
A regular expression
証明書 ID を抽出するフィルターとして使用する正規表現。表現には 1 つのグループを含める必要があります。
User Mapping Method
証明書 ID を既存ユーザーに一致させる方法を定義します。Username or email は、ユーザー名またはメールアドレスで既存のユーザーを検索します。Custom Attribute Mapperは、証明書 ID と一致するカスタム属性を持つ既存のユーザーを検索します。カスタム属性の名前は設定可能です。
A name of user attribute
値が証明書アイデンティティーと照合されるカスタム属性。属性マッピングが複数の値に関連する場合は、複数のカスタム属性を使用します(例:「Certificate Serial Number and IssuerDN」)。
CRL Checking Enabled
Certificate Revocation List を使用して、証明書の失効ステータスを確認します。リストの場所は、CRL file path 属性で定義されます。
Enable CRL Distribution Point to check certificate revocation status
CDP を使用して、証明書失効ステータスを確認します。ほとんどの PKI 認証局には、証明書に CDP が含まれます。
CRL file path
CRL 一覧が含まれるファイルへのパス。CRL Checking Enabled オプションが有効になっている場合、値は有効なファイルへのパスである必要があります。
OCSP Checking Enabled
Online Certificate Status Protocol を使用して、証明書失効ステータスを確認します。
OCSP Fail-Open Behavior
デフォルトでは、認証を成功させるために、OCSP チェックは肯定応答を返す必要があります。ただし、このチェックが決定的でない場合があります。たとえば、OCSP サーバーに到達できない、過負荷になっている、またはクライアント証明書に OCSP レスポンダー URI が含まれていない可能性があります。この設定をオンにすると、OCSP レスポンダーが明示的な否定応答を受信し、証明書が確実に取り消された場合にのみ、認証が拒否されます。有効な OCSP 応答がない場合は、認証試行が許可されます。
OCSP Responder URI
証明書の OCSP レスポンダー URI の値を上書きします。
Validate Key Usage
証明書の KeyUsage 拡張ビットが設定されていることを検証します。たとえば、「digitalSignature,KeyEncipherment」は、KeyUsage 拡張のビット 0 と 2 が設定されているかどうかを検証します。Key Usage の検証を無効にするには、このパラメーターを空欄のままにします。詳細は、RFC5280, Section-4.2.1.3 を参照してください。キーの使用が一致しないと、Red Hat Single Sign-On はエラーを発生させます。
Validate Extended Key Usage
Extended Key Usage 拡張で定義された 1 つまたは複数の目的を検証します。詳細は、RFC5280, Section-4.2.1.12 を参照してください。Extended Key Usage の検証を無効にするには、このパラメーターを空欄のままにします。発行元の CA によってクリティカルとフラグが付けられ、キーの使用拡張の不一致が発生した場合、Red Hat Single Sign-On はエラーを発生させます。
証明書ポリシーの検証
証明書ポリシー拡張で定義されている 1 つ以上のポリシー OID を確認します。RFC5280 のセクション -4.2.1.4 を参照してください。証明書要求の検証を無効にするには、パラメーターを空のままにします。複数のポリシーはコンマで区切る必要があります。
証明書ポリシーの検証モード
Validate Certificate Policy 設定で複数のポリシーが指定されている場合、要求されたすべてのポリシーが存在するかどうかを照合で確認するか、認証を成功させるには 1 つの照合で十分かを判断します。デフォルト値は All です。つまり、要求されたポリシーすべてがクライアント証明書に存在する必要があることを意味します。
Bypass identity confirmation
有効にすると、X.509 クライアント証明書認証は、証明書 ID を確認するようにユーザーに要求しません。Red Hat Single Sign-On は、認証に成功するとユーザーにサインインします。
Revalidate client certificate
設定された場合、クライアント証明書のトラストチェーンは、設定されたトラストストアにある証明書を使用して、アプリケーションレベルで常に検証されます。これは、基礎となる Web サーバーがクライアント証明書チェーンの検証を強制しない場合に便利です (非検証のロードバランサーやリバースプロキシーの背後にある場合や、相互 SSL ネゴシエーションについて許可される CA の数が大きすぎる場合など (ほとんどのブラウザーは最大の SSL ネゴシエーションパケットのサイズを 32767 バイトに制限します。これは、約 200 の広告済み CA に対応します)。デフォルトでは、このオプションは無効です。

8.5.5. X.509 クライアント証明書認証の Direct Grant Flow への追加

  1. メニューで Authentication をクリックします。
  2. 「Direct Grant」フローをクリックします。
  3. Copy をクリックして、「Direct Grant」フローのコピーを作成します。
  4. コピーの名前を入力します。
  5. OK をクリックします。
  6. 「Username Validation」の Actions リンクをクリックし、Delete をクリックします。
  7. Delete をクリックします。
  8. 「Password」の Actions リンクをクリックし、Delete をクリックします。
  9. Delete をクリックします。
  10. Add execution をクリックします。
  11. 「X509/Validate Username」をクリックします。
  12. Save をクリックします。

    X509 直接付与実行

    X509 Direct Grant Execution

  13. X509 ブラウザーフロー セクションに記載の手順に従って、x509 認証設定をセットアップします。
  14. Bindings タブをクリックします。
  15. Direct Grant Flow ドロップダウンリストをクリックします。
  16. 新規作成された「x509 Direct Grant」フローをクリックします。
  17. Save をクリックします。

    X509 直接付与フローバインディング

    X509 Direct Grant Flow Bindings

8.5.6. クライアント証明書ルックアップ

Red Hat Single Sign-On サーバーが直接 HTTP リクエストを受け取ると、JBoss EAP undertow サブシステムは SSL ハンドシェイクを確立し、クライアント証明書を抽出します。JBoss EAP は、サーブレット仕様で指定されたように、HTTP リクエストの javax.servlet.request.X509Certificate 属性にクライアント証明書を保存します。Red Hat Single Sign-On X509 オーセンティケーターは、この属性から証明書を検索できます。

ただし、Red Hat Single Sign-On サーバーがロードバランサーまたはリバースプロキシーの背後で HTTP リクエストをリッスンする場合は、プロキシーサーバーはクライアント証明書を抽出し、相互 SSL 接続を確立する場合があります。リバースプロキシーは通常、認証されたクライアント証明書をベースのリクエストの HTTP ヘッダーに配置します。プロキシーはリクエストをバックエンド Red Hat Single Sign-On サーバーに転送します。この場合、Red Hat Single Sign-On は、HTTP リクエストの属性ではなく、HTTP ヘッダーから X.509 証明書チェーンを検索する必要があります。

Red Hat Single Sign-On がリバースプロキシーの背後にある場合は、通常 RHSSO_HOME/standalone/configuration/standalone.xml で x509cert-lookup SPI の代替プロバイダーを設定する必要があります。HTTP ヘッダー証明書を検索する default のプロバイダーでは、さらにhaproxyapache の 2 つの組み込みプロバイダーが存在します。

8.5.6.1. HAProxy 証明書ルックアッププロバイダー

Red Hat Single Sign-On サーバーが HAProxy リバースプロキシーの背後に配置されると、このプロバイダーを使用します。サーバーには以下の設定を使用します。

<spi name="x509cert-lookup">
    <default-provider>haproxy</default-provider>
    <provider name="haproxy" enabled="true">
        <properties>
            <property name="sslClientCert" value="SSL_CLIENT_CERT"/>
            <property name="sslCertChainPrefix" value="CERT_CHAIN"/>
            <property name="certificateChainLength" value="10"/>
        </properties>
    </provider>
</spi>

この設定例では、クライアント証明書が HTTP ヘッダーSSL_CLIENT_CERTから検索され、そのチェーンからの他の証明書が CERT_CHAIN_0 から CERT_CHAIN_9 までの HTTP ヘッダーから検索されます。属性certificateChainLength はチェーンの最大長であるため、最後の属性は CERT_CHAIN_9 になります。

クライアント証明書の HTTP ヘッダーおよびクライアント証明書チェーンの設定についての詳細は、HAProxy のドキュメントを参照してください。

8.5.6.2. Apache 証明書ルックアッププロバイダー

Red Hat Single Sign-On サーバーが Apache リバースプロキシーの背後にある場合は、このプロバイダーを使用できます。サーバーには以下の設定を使用します。

<spi name="x509cert-lookup">
    <default-provider>apache</default-provider>
    <provider name="apache" enabled="true">
        <properties>
            <property name="sslClientCert" value="SSL_CLIENT_CERT"/>
            <property name="sslCertChainPrefix" value="CERT_CHAIN"/>
            <property name="certificateChainLength" value="10"/>
        </properties>
    </provider>
</spi>

この設定は、haproxy プロバイダーと同じです。クライアント証明書の HTTP ヘッダーおよびクライアント証明書チェーンの設定方法の詳細については、mod_ssl および mod_headers の Apache ドキュメントを参照してください。

8.5.6.3. NGINX 証明書ルックアッププロバイダー

Red Hat Single Sign-On サーバーが NGINX リバースプロキシーの背後に配置されると、このプロバイダーを使用できます。サーバーには以下の設定を使用します。

<spi name="x509cert-lookup">
    <default-provider>nginx</default-provider>
    <provider name="nginx" enabled="true">
        <properties>
            <property name="sslClientCert" value="ssl-client-cert"/>
            <property name="sslCertChainPrefix" value="USELESS"/>
            <property name="certificateChainLength" value="2"/>
        </properties>
    </provider>
</spi>
注記

NGINX SSL/TLS モジュール は、クライアント証明書チェーンを公開しません。Red Hat Single Sign-On の NGINX 証明書ルックアッププロバイダーは、Keycloak トラストストア を使用して再ビルドします。クライアント証明書チェーンを再構築するために、すべてのルートおよび中間 CA で keytool CLI を使用して Red Hat Single Sign-On トラストストアに反映させます。

クライアント証明書の HTTP ヘッダーの設定の詳細については、NGINX のドキュメントを参照してください。

NGINX 設定ファイルの例:

 ...
 server {
    ...
    ssl_client_certificate                  trusted-ca-list-for-client-auth.pem;
    ssl_verify_client                       optional_no_ca;
    ssl_verify_depth                        2;
    ...
    location / {
      ...
      proxy_set_header ssl-client-cert        $ssl_client_escaped_cert;
      ...
    }
    ...
}
注記

trusted-ca-list-for-client-auth.pem のすべての証明書を Keycloak トラストストア に追加する必要があります。

8.5.6.4. 他のリバースプロキシーの実装

Red Hat Single Sign-Onには、他のリバースプロキシー実装に対する組み込みサポートはありません。ただし、apache または haproxy と同様に動作する、他のリバースプロキシーを作成できます。これらのいずれも機能しない場合、org.keycloak.services.x509.X509ClientCertificateLookupFactory および org.keycloak.services.x509.X509ClientCertificateLookup プロバイダーの独自の実装を作成します。プロバイダーの追加方法に関する詳細は、Server Developer Guide を参照してください。

8.5.7. トラブルシューティング

HTTP ヘッダーのダンプ
リバースプロキシーがKeycloak に何を送信するかを確認するには、RequestDumpingHandler Undertow フィルターを有効にし、server.log ファイルを参照してください。
logging サブシステムで TRACE ロギングを有効化
...
    <profile>
        <subsystem xmlns="urn:jboss:domain:logging:8.0">
...
            <logger category="org.keycloak.authentication.authenticators.x509">
                <level name="TRACE"/>
            </logger>
            <logger category="org.keycloak.services.x509">
                <level name="TRACE"/>
            </logger>
警告

実稼働環境では、RequestDumpingHandler または TRACE ロギングを使用しないでください。

X.509 での直接認証
以下のテンプレートを使用して、Resource Owner Password Credentials Grant を使用してトークンを要求できます。
$ curl https://[host][:port]/auth/realms/master/protocol/openid-connect/token \
       --insecure \
       --data "grant_type=password&scope=openid profile&username=&password=&client_id=CLIENT_ID&client_secret=CLIENT_SECRET" \
       -E /path/to/client_cert.crt \
       --key /path/to/client_cert.key
[source]
[host][:port]
リモート Red Hat Single Sign-On サーバーのホストおよびポート番号。
CLIENT_ID
クライアント ID。
CLIENT_SECRET
機密クライアントの場合は、クライアントシークレットです。
client_cert.crt
相互 SSL 認証でクライアントの ID を検証するための公開鍵証明書。証明書は PEM 形式である必要があります。
client_cert.key
公開鍵のペアの秘密鍵。このキーは PEM 形式である必要があります。

8.6. W3C Web Authentication (WebAuthn)

Red Hat Single Sign-On は、W3C Web 認証 (WebAuthn) のサポートを提供します。Red Hat Single Sign-On は、WebAuthn の Relying Party(RP) として機能します。

注記

WebAuthn 操作が成功するかどうかは、オーセンティケーター、ブラウザー、およびプラットフォームをサポートするユーザーの WebAuthn によります。オーセンティケーター、ブラウザー、およびプラットフォームが WebAuthn 仕様をサポートしていることを確認してください。

8.6.1. 設定

2FA の WebAuthn サポートの設定手順は、以下のようになります。

8.6.1.1. WebAuthn オーセンティケーター登録の有効化

  1. メニューで Authentication をクリックします。
  2. Required Actions タブをクリックします。
  3. Register をクリックします。
  4. Required Action ドロップダウンリストをクリックします。
  5. Webauthn Register をクリックします。
  6. OK をクリックします。

すべての新規ユーザーに WebAuthn 認証情報の登録を要求する必要がある場合は、Default Action チェックボックスにマークを付けます。

8.6.1.2. WebAuthn 認証のブラウザーフローへの追加

  1. メニューで Authentication をクリックします。
  2. Browser フローをクリックします。
  3. Copy をクリックして、ビルトインの Browser フローのコピーを作成します。
  4. コピーの名前を入力します。
  5. OK をクリックします。
  6. WebAuthn Browser Browser- Conditional OTPActions リンクをクリックし、Delete をクリックします。
  7. Delete をクリックします。

全ユーザーの WebAuthn が必要な場合は、以下を実行します。

  1. WebAuthn Browser FormsActions リンクをクリックします。
  2. Add execution をクリックします。
  3. Provider ドロップダウンリストをクリックします。
  4. WebAuthn Authenticator をクリックします。
  5. Save をクリックします。
  6. WebAuthn AuthenticatorREQUIRED をクリックします。

    webauthn browser flow required

  7. Bindings タブをクリックします。
  8. Browser Flow ドロップダウンリストをクリックします。
  9. WebAuthn Browser をクリックします。
  10. Save をクリックします。
注記

ユーザーに WebAuthn 認証情報がない場合、ユーザーは WebAuthn 認証情報を登録する必要があります。

WebAuthn 認証情報が登録されている場合に限り、ユーザーはWebAuthn でログインできます。そのため、WebAuthn Authenticator 実行を追加する代わりに、以下を実行できます。

手順

  1. WebAuthn Browser FormsActions リンクをクリックします。
  2. Add flow をクリックします。
  3. Alias フィールドに「Conditional 2FA」を入力します。
  4. Save をクリックします。
  5. Conditional 2FACONDITIONAL をクリックします。
  6. Conditional 2FAActions リンクをクリックします。
  7. Add execution をクリックします。
  8. Provider ドロップダウンリストをクリックします。
  9. Condition - User Configured をクリックします。
  10. Save をクリックします。
  11. Conditional 2FAREQUIRED をクリックします。
  12. Conditional 2FAActions リンクをクリックします。
  13. Add execution をクリックします。
  14. Provider ドロップダウンリストをクリックします。
  15. WebAuthn Authenticator をクリックします。
  16. Save をクリックします。
  17. Conditional 2FAALTERNATIVE をクリックします。

    webauthn browser flow conditional

ユーザーは、2 つ目の要素に WebAuthn または OTP のいずれかを使用することを選択できます。

手順

  1. Conditional 2FAActions リンクをクリックします。
  2. Add execution をクリックします。
  3. Provider ドロップダウンリストをクリックします。
  4. ITP Form をクリックします。
  5. Save をクリックします。
  6. Conditional 2FAALTERNATIVE をクリックします。

    webauthn browser flow conditional with OTP

8.6.2. WebAuthn オーセンティケーターを使用した認証

WebAuthn オーセンティケーターを登録した後に、ユーザーは以下の操作を実行します。

  • ログインフォームを開きます。ユーザーは、ユーザー名とパスワードで認証する必要があります。
  • ユーザーのブラウザーは、WebAuthn オーセンティケーターを使用して認証することをユーザーに要求します。

8.6.3. 管理者として WebAuthn の管理

8.6.3.1. 認証情報の管理

Red Hat Single Sign-On は、ユーザー認証情報の管理 からの他の認証情報と同様に、WebAuthn 認証情報を管理します。

  • Red Hat Single Sign-On は、Reset Actions の一覧から WebAuthn 認証情報を作成するのに必要なアクションをユーザーに割り当て、Webauthn Register を選択します。
  • 管理者は Delete をクリックして WebAuthn 認証情報を削除できます。
  • 管理者は、Show data…​ を選択して、AAGUID などの認証情報のデータを表示することができます。
  • 管理者は、User Label フィールドに値を設定し、データを保存することで、認証情報のラベルを設定できます。

8.6.3.2. ポリシーの管理

管理者は、WebAuthn 関連の操作をレルムごとに WebAuthn Policy として設定できます。

手順

  1. メニューで Authentication をクリックします。
  2. WebAuthn Policy タブをクリックします。
  3. ポリシー内で項目を設定します(以下の説明を参照してください)。
  4. Save をクリックします。

設定可能な項目とその説明は以下のとおりです。

設定説明

エンティティー名の使用

WebAuthn Relying Party として読み取り可能なサーバー名。この項目は必須であり、WebAuthn オーセンティケーターの登録に適用されます。デフォルト設定は「keycloak」です。詳細は、「WebAuthn Specification」を参照してください。

署名アルゴリズム

アルゴリズム。公開鍵認証情報 に使用する署名アルゴリズムを WebAuthn オーセンティケーターに指示します。Red Hat Single Sign-On は、公開鍵認証情報を使用して 認証アサーションに署名し、検証します。アルゴリズムが存在しない場合は、デフォルトの ES256 が適合されます。ES256 は、WebAuthn オーセンティケーターの登録に適用されるオプションの設定項目です。詳細は、「WebAuthn Specification」を参照してください。

パート ID の使用

公開鍵認証情報 のスコープを決定する WebAuthn Relying Party の ID。ID は、オリジンの有効なドメインでなければなりません。この ID は、WebAuthn オーセンティケーターの登録に適用されるオプションの設定項目です。このエントリーが空白の場合、Red Hat Single Sign-On は Red Hat Single Sign-On のベース URL のホスト部分を適合します。詳細は、WebAuthn の仕様 を参照してください。

証明の伝達設定

ブラウザーでの WebAuthn API 実装(WebAuthn Client)は、Attestation ステートメントを生成するのに推奨される方法です。この設定は、WebAuthn オーセンティケーターの登録に適用されるオプションの設定項目です。オプションが存在しない場合、その動作は「none」の選択と同じになります。詳細は、WebAuthn の仕様 を参照してください。

オーセンティケーター添付

WebAuthn Client に対する WebAuthn オーセンティケーターの許容割り当てパターン。このパターンは、WebAuthn オーセンティケーターの登録に適用されるオプションの設定項目です。詳細は、「WebAuthn Specification」を参照してください。

識別キーが必要

WebAuthn オーセンティケーターが クライアント側の公開鍵認証情報ソース として公開鍵認証情報を生成することを要求するオプション。このオプションは、WebAuthn オーセンティケーターの登録に適用されます。空欄のままにすると、その動作は「No」の選択と同じになります。詳細は、「WebAuthn Specification」を参照してください。

ユーザー検証要件

WebAuthn オーセンティケーターがユーザーの検証を確認することを要求するオプション。これは、WebAuthn オーセンティケーターの登録と、WebAuthn オーセンティケーターによるユーザーの認証に適用される任意の設定項目です。オプションが存在しない場合、その動作は「preferred」の選択と同じになります。詳細は、「WebAuthn Specification for registering a WebAuthn authenticator」および「WebAuthn Specification for authenticating the user by a WebAuthn authenticator」を参照してください。

タイムアウト

WebAuthn オーセンティケーターを登録し、WebAuthn オーセンティケーターを使用してユーザーを認証する際のタイムアウト値(秒単位)。ゼロに設定すると、その動作は WebAuthn オーセンティケーターの実装により異なります。デフォルト値は 0 です。詳細は、「WebAuthn Specification for registering a WebAuthn authenticator」および「WebAuthn Specification for authenticating the user by a WebAuthn authenticator」を参照してください。

同じオーセンティケーター登録の回避

有効にすると、Red Hat Single Sign-On は、すでに登録されている WebAuthn オーセンティケーターを再登録できません。

許可される AAGUID

WebAuthn オーセンティケーターが登録する必要のある AAGUID のホワイトリスト。

8.6.4. 証明ステートメントの検証

WebAuthn オーセンティケーターを登録すると、Red Hat Single Sign-On は、WebAuthn オーセンティケーターが生成した証明ステートメントの信頼性を検証します。Red Hat Single Sign-On では、これにトラストアンカーの証明書が必要です。Red Hat Single Sign-On は Keycloak トラストストア を使用するので、事前にこれらの証明書をインポートする必要があります。

この検証を省略するには、このトラストストアを無効にするか、または WebAuthn ポリシーの設定項目「Attestation Conveyance Preference」を「none」に設定します。

8.6.5. ユーザーとして WebAuthn 認証情報の管理

8.6.5.1. WebAuthn オーセンティケーターの登録

WebAuthn オーセンティケーターを登録する適切な方法は、ユーザーが Red Hat Single Sign-On にアカウントを登録しているかどうかによって異なります。

8.6.5.2. 新規ユーザー

レルムで WebAuthn Register の必須操作がDefault Action の場合、新規ユーザーは初回ログインの後に WebAuthn セキュリティーキーを設定する必要があります。

手順

  1. ログインフォームを開きます。
  2. Register をクリックします。
  3. フォームの項目に入力します。
  4. Register をクリックします。

登録に成功すると、ブラウザーは、ユーザーに対してWebAuthn オーセンティケーターのラベルのテキストを入力するよう要求します。

8.6.5.3. 既存ユーザー

最初の例のように WebAuthn Authenticator が必要に応じて設定されている場合、既存のユーザーがログインを試みる際に、WebAuthn オーセンティケーターを自動的に登録する必要があります。

手順

  1. ログインフォームを開きます。
  2. フォームの項目に入力します。
  3. Save をクリックします。
  4. Login をクリックします。

登録に成功すると、ユーザーのブラウザーは、ユーザーに対してWebAuthn オーセンティケーターのラベルのテキストを入力するよう要求します。

8.6.6. パスワードなしの WebAuthn と 2 つのファクターの組み合わせ

Red Hat Single Sign-On は、2 要素認証に WebAuthn を使用しますが、第一要素認証として WebAuthn を使用できます。この場合、パスワードなし の WebAuthn 認証情報を持つユーザーは、パスワードなしで Red Hat Single Sign-On に対して認証できます。Red Hat Single Sign-Onでは、レルムおよび単一の認証フローのコンテキストで、パスワードなしおよび2 要素の認証メカニズムの両方として WebAuthn を使用できます。

管理者は、通常、WebAuthn パスワードレス認証用にユーザーが登録するセキュリティーキーが異なる要件を満たすことを要求します。たとえば、ユーザーは、PIN を使用してセキュリティーキーに対して認証することが要求される場合があります。あるいは、セキュリティーキーを強力な認証局で認証する必要があります。

このため、Red Hat Single Sign-On では、管理者は個別の WebAuthn Passwordless Policy を設定できます。必須のWebauthn Register Passwordlessアクションタイプと、別のWebAuthn Passwordless Authenticatorオーセンティケータータイプがあります。

8.6.6.1. 設定

手順

以下のように WebAuthn パスワードレスサポートを設定します。

  1. WebAuthn パスワードレスサポートに新しい必須アクションを登録します。「WebAuthn オーセンティケーター登録の有効化」で説明されている手順を使用します。Webauthn Register Passwordless アクションを登録します。
  2. ポリシーを設定します。「ポリシーの管理」で説明されている手順および設定オプションを使用できます。管理コンソールのWebAuthn Passwordless Policy タブで、設定を実行します。通常、セキュリティーキーの要件は、2 要素ポリシーよりもより強力になります。たとえば、パスワードレスポリシーの設定時に、User Verification RequirementRequired に設定できます。
  3. 認証フローを設定します。「WebAuthn 認証のブラウザーフローへの追加」で説明されている WebAuthn Browser フローを使用します。以下のようにフローを設定します。

    • WebAuthn Browser Forms サブフローには、最初のオーセンティケーターとして Username Form が含まれます。デフォルトの Username Password Form オーセンティケーターを削除し、Username Form オーセンティケーターを追加します。このアクションでは、ユーザーに最初のステップとしてユーザー名を提供することを要求します。
    • 必須のサブフローがある場合があります(例: Passwordless Or Two-factor)。このサブフローは、ユーザーがPasswordless WebAuthn 認証情報または Two-factor 認証で認証できることを示しています。
    • フローには、第一の代替として WebAuthn Passwordless Authenticator が含まれます。
    • 2 つ目の代替は、Password And Two-factor Webauthn (例)という名前のサブフローです。このサブフローには、Password Form および WebAuthn Authenticator が含まれます。

フローの最終的な設定は以下のようになります。

PasswordLess フロー

PasswordLess flow

Red Hat Single Sign-On にすでに知られているユーザーに、必要なアクションとして WebAuthn Register Passwordless を追加してテストできるようになりました。第一の認証時に、ユーザーはパスワードおよび第二要素の WebAuthn 認証情報を使用する必要があります。WebAuthn Passwordless認証情報を使用する場合、ユーザーはパスワードおよび第二要素の WebAuthn 認証情報を提供する必要はありません。

8.6.7. LoginLess WebAuthn

Red Hat Single Sign-On は、2 要素認証に WebAuthn を使用しますが、第一要素認証として WebAuthn を使用できます。この場合、パスワードなし の WebAuthn 認証情報を持つユーザーは、ログインやパスワードなしで Red Hat Single Sign-On に対して認証できます。Red Hat Single Sign-On は、レルムのコンテキストで、ログインレス/パスワードレスおよび 2 要素認証メカニズムの両方として WebAuthn を使用できます。

管理者は、通常、WebAuthn ログインレス認証用にユーザーが登録するセキュリティーキーが異なる要件を満たすことを要求します。ログインレス認証では、ユーザーがセキュリティーキーに対して認証する必要があり (たとえば、PIN コードまたは指紋を使用して)、ログインレスクレデンシャルに関連付けられた暗号化キーがセキュリティーキーに物理的に保存されている必要があります。すべてのセキュリティーキーがそのような要件を満たしているわけではありません。デバイスがユーザー検証および常駐キーをサポートしているかどうかをセキュリティーキーベンダーに確認してください。サポートされているセキュリティーキー を参照してください。

Red Hat Single Sign-On により、管理者はログインレス認証を可能にする方法で WebAuthn Passwordless Policy を設定できます。ログインレス認証は、WebAuthn Passwordless PolicyWebAuthn Passwordless クレデンシャルでのみ設定できることに注意してください。WebAuthn ログインレス認証と WebAuthn パスワードレス認証は同じレルムで設定できますが、同じポリシー WebAuthn Passwordless Policy ポリシーを共有します。

8.6.7.1. 設定

手順

以下のように WebAuthn ログインレスサポートを設定します。

  1. WebAuthn パスワードレスサポートに新しい必須アクションを登録します。「WebAuthn オーセンティケーター登録の有効化」で説明されている手順を使用します。Webauthn Register Passwordless アクションを登録します。
  2. WebAuthn Passwordless Policy を設定します。管理コンソールの Authentication セクションの WebAuthn Passwordless Policy タブで設定を実行します。ログインレスシナリオのポリシーを設定するときは、User Verification Requirementrequired に、Require Resident KeyYes に設定する必要があります。専用のログインレスポリシーがないため、認証シナリオをユーザー verification=no/resident key=no および loginless のシナリオと混在させることはできません (ユーザー verification=yes/resident key=yes)。ストレージ容量は通常、セキュリティーキーによって非常に制限されています。つまり、多くの常駐キーをセキュリティーキーに保存できません。
  3. 認証フローを設定します。新しい認証フローを作成し、WebAuthn Passwordless 実行を追加して、実行の Requirement 設定を Required に設定します

フローの最終的な設定は以下のようになります。

LoginLess フロー

LoginLess flow

Red Hat Single Sign-On にすでに知られているユーザーに、必要なアクションとして WebAuthn Register Passwordless を追加してテストできるようになりました。必要なアクションが設定されているユーザーは、(たとえば、ユーザー名/パスワードを使用して) 認証する必要があり、ログインレス認証に使用するセキュリティーキーを登録するように求められます。

8.6.7.2. ベンダー固有のマーク

8.6.7.2.1. 互換性チェックリスト

Red Hat Single Sign-On を使用したログインレス認証には、次の機能を満たすためのセキュリティーキーが必要です

  • FIDO2 コンプライアンス: FIDO/U2F と混同しないでください
  • ユーザー検証: セキュリティーキーがユーザーを認証する機能 (誰かがセキュリティーキーを見つけてログインなしおよびパスワードなしで認証できるようにする)
  • 常駐キー: クライアントアプリケーションに関連付けられたログインキーと暗号化キーを保存するセキュリティーキーの機能
8.6.7.2.2. Windows Hello

Windows Hello ベースの資格情報を使用して Red Hat Single Sign-On に対して認証するには、WebAuthn Passwordless PolicySignature Algorithms 設定に RS256 値を含めるように設定します。一部のブラウザーでは、プライベートウィンドウ内のプラットフォームセキュリティーキー (Windows Hello など) へのアクセスが許可されていないことに注意してください。

8.6.7.2.3. サポートされているセキュリティーキー

以下のセキュリティーキーは、Red Hat Single Sign-On を使用したログインレス認証で正常にテストされています。

  • Windows Hello (Windows 10 21H1/21H2)
  • Yubico Yubikey 5 NFC
  • Feitian ePass FIDO-NFC

8.7. リカバリーコード (RecoveryCodes)

認証フローに 2 要素認証システムとして回復認証コードフォームを追加することにより、2 要素認証の回復コードを設定できます。このオーセンティケーターの設定例については、WebAuthn を参照してください。

注記

RecoveryCodesl は テクノロジープレビュー であるため、完全にサポートされていません。この機能はデフォルトで無効にされています。

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

8.8. 条件付きフローの条件

実行要件 のセクションで説明されているように、Condition 実行は Conditional サブフローにのみ含めることができます。すべての条件実行が true と評価されると、Conditional サブフローは Required として機能します。Conditional サブフローの次の実行を処理できます。Conditional サブフローに含まれる一部の実行が false と評価されると、サブフロー全体が Disabled と見なされます。

8.8.1. 利用可能な条件

Condition - User Role

この実行では、ユーザーに User role フィールドで定義されているロールがあるかどうかを判別できます。ユーザーに必要なロールが割り当てられている場合、実行は true と判断され、その他の実行が評価されます。管理者は以下のフィールドを定義する必要があります。

Alias
認証フローに表示される実行の名前を記述します。
User role
このフローを実行するために必要なユーザーロール。アプリケーションロールを指定する場合、構文は appname.approlemyapp.myroleなど)です。
Condition - User Configured
これは、フローの他の実行がユーザーに設定されているかどうかを確認します。実行要件のセクションには、OTP フォームの例が含まれています。
Condition - User Attribute

これは、ユーザーが必要な属性を設定しているかどうかを確認します。出力が否定される可能性があります。この場合、ユーザーに属性を設定することはできません。ユーザー属性 セクションでは、カスタム属性の追加方法を示します。以下のフィールドを指定できます。

Alias
認証フローに表示される実行の名前を記述します。
Attribute name
確認する属性の名前。
Expected attribute value
属性の想定される値。
Negate output
出力を否定することができます。つまり、この属性は存在しません。

8.8.2. 条件付きフローでのアクセスの明示的な拒否/許可

条件付きフローのリソースへのアクセスを許可または拒否できます。2 つのオーセンティケーターの Deny AccessAllow Access は、条件でリソースへのアクセスを制御します。

Allow Access
オーセンティケーターは常に認証に成功します。このオーセンティケーターは設定できません。
Deny Access

アクセスは常に拒否されます。ユーザーに表示されるエラーメッセージを定義できます。以下のフィールドを指定できます。

Alias
認証フローに表示される実行の名前を記述します。
エラーメッセージ
ユーザーに表示されるエラーメッセージ。エラーメッセージは、特定のメッセージまたはローカリゼーションで使用するためのプロパティーとして提供できます(例:「You do not have the role 'admin'."、メッセージプロパティーの my-property-deny)。プロパティー access-deniedとして定義されたデフォルトメッセージは空欄のままにします。

以下の例は、ロールrole1 を持たないすべてのユーザーのアクセスを拒否し、プロパティー deny-role1 で定義されたエラーメッセージを表示する方法を示しています。この例には、Condition - User Role および Deny Access 実行が含まれます。

ブラウザーのフロー

deny access flow

Condition - user role configuration

deny access role condition

Deny Access の設定は非常に簡単です。以下のように、任意のエイリアスと必要なメッセージを指定できます。

deny access execution cond

最後に、ログインテーマのエラーメッセージのプロパティー messages_en.properties(英語の場合)を定義します。

deny-role1 = You do not have required role!

第9章 アイデンティティープロバイダーの統合

Identity Broker は、サービスプロバイダーをアイデンティティープロバイダーに接続する中間サービスです。アイデンティティープロバイダーは外部アイデンティティープロバイダーとの関係を作成し、プロバイダーのアイデンティティーを使用してサービスプロバイダーが公開する内部サービスにアクセスします。

ユーザーの観点からすると、アイデンティティーブローカーは、セキュリティードメインおよびレルムのアイデンティティーを管理するユーザー中心の一元的な方法を提供します。アカウントをアイデンティティープロバイダーからの 1 つまたは複数のアイデンティティーとリンクすることや、プロバイダーからの ID 情報に基づいてアカウントを作成することができます。

アイデンティティープロバイダーは特定のプロトコルに基づき、これを使用して認証を行い認証および承認情報をユーザーに送付します。以下をアイデンティティープロバイダーとすることができます。

  • Facebook、Google、Twitter などのソーシャルプロバイダー。
  • そのユーザーがお客様のサービスにアクセスする必要があるビジネスパートナー。
  • 統合するクラウドベースのアイデンティティーサービス。

通常、Red Hat Single Sign-On は、以下のプロトコルで ID プロバイダーをサポートとします。

  • SAML v2.0
  • OpenID Connect v1.0
  • OAuth v2.0

9.1. ブローカーの概要

Red Hat Single Sign-On をアイデンティティーブローカーとして使用する場合、Red Hat Single Sign-Onは特定のレルムで認証するのにユーザーに対してクレデンシャルの提供を強制しません。Red Hat Single Sign-On は、認証が可能なアイデンティティープロバイダーの一覧を表示します。

デフォルトのアイデンティティープロバイダーを設定した場合、Red Hat Single Sign-On はユーザーをデフォルトのプロバイダーにリダイレクトします。

注記

プロトコルによって異なる認証フローが必要になる場合があります。Red Hat Single Sign-On でサポートされるすべてのアイデンティティープロバイダーは、以下のフローを使用します。

アイデンティティーブローカーフロー

Identity broker flow

  1. 認証されていないユーザーは、クライアントアプリケーションの保護されているリソースを要求します。
  2. クライアントアプリケーションは、認証のためにユーザーを Red Hat Single Sign-On にリダイレクトします。
  3. Red Hat Single Sign-On は、レルムに設定されたアイデンティティープロバイダーの一覧と共にログインページを表示します。
  4. ユーザーは、ボタンまたはリンクをクリックしてアイデンティティープロバイダーの 1 つを選択します。
  5. Red Hat Single Sign-On は、ターゲットのアイデンティティープロバイダーに認証要求を発行して認証を要求し、ユーザーをアイデンティティープロバイダーのログインページにリダイレクトします。管理者は、すでに管理コンソールのアイデンティティープロバイダーの接続プロパティーおよびその他の設定オプションを設定しています。
  6. ユーザーは、アイデンティティープロバイダーと認証を行うための認証情報または同意を提供します。
  7. アイデンティティープロバイダーによる認証に成功すると、ユーザーは認証応答と共に Red Hat Single Sign-On にリダイレクトされます。通常、応答には、アイデンティティープロバイダーの認証を信頼し、ユーザー情報を取得するために Red Hat Single Sign-On が使用するセキュリティートークンが含まれます。
  8. Red Hat Single Sign-On は、アイデンティティープロバイダーからの応答が有効かどうかを確認します。有効な場合、Red Hat Single Sign-On は、ユーザーが存在しない場合に、ユーザーをインポートして作成します。トークンに必要な情報が含まれていない場合、Red Hat Single Sign-On はアイデンティティープロバイダーに追加のユーザー情報を求める場合があります。この動作は ID フェデレーション です。ユーザーがすでに存在する場合、Red Hat Single Sign-On は、アイデンティティープロバイダーから返されたアイデンティティーを既存のアカウントにリンクするようユーザーに要求します。この動作は、アカウントのリンク です。Red Hat Single Sign-On では、アカウントのリンク を設定し、それをFirst Login Flow で指定できます。このステップで、Red Hat Single Sign-On はユーザーを認証し、サービスプロバイダー内の要求されたリソースにアクセスためのそのトークンを発行します。
  9. ユーザーが認証されたら、Red Hat Single Sign-On は、前のステップのローカル認証時に発行されたトークンを送信することで、ユーザーをサービスプロバイダーにリダイレクトします。
  10. サービスプロバイダーは Red Hat Single Sign-On からトークンを受け取り、保護されたリソースへのアクセスを許可します。

このフローのバリエーションが可能です。たとえば、クライアントアプリケーションは、アイデンティティープロバイダーのリストを表示するのではなく特定のプロバイダーを要求することや、Red Hat Single Sign-On を設定して、アイデンティティーのフェデレーションを行う前にユーザーに追加情報の提供を強制することができます。

認証プロセスの最後に、Red Hat Single Sign-On はそのトークンをクライアントアプリケーションに対して発行します。クライアントアプリケーションは外部のアイデンティティープロバイダーから分離されるため、クライアントアプリケーションのプロトコルやユーザーのアイデンティティーの検証方法を確認できません。プロバイダーが把握する必要があるのは、Red Hat Single Sign-On のみです。

9.2. デフォルトのアイデンティティープロバイダー

Red Hat Single Sign-Onは、ログインフォームを表示する代わりに、アイデンティティープロバイダーにリダイレクトすることができます。このリダイレクトを有効にするには、以下を実行します。

手順

  1. メニューで Authentication をクリックします。
  2. Browser フローをクリックします。
  3. ドロップダウンリストから Identity Provider Redirector を選択します。
  4. Default Identity Provider を、ユーザーをリダイレクトするアイデンティティープロバイダーに設定します。

Red Hat Single Sign-On が設定されたデフォルトのアイデンティティープロバイダーを見つけられない場合は、ログインフォームが表示されます。

このオーセンティケーターは、kc_idp_hint クエリーパラメーターを処理します。詳細は、「クライアントが推奨するアイデンティティープロバイダー」のセクションを参照してください。

9.3. 一般的な設定

アイデンティティーブローカー設定の基盤は、アイデンティティープロバイダー(IDP)です。Red Hat Single Sign-On は、各レルムにアイデンティティープロバイダーを作成し、デフォルトではすべてのアプリケーションに対してこれらのアイデンティティープロバイダーを有効にします。レルムからのユーザーは、アプリケーションへのサインイン時に登録されたいずれかのアイデンティティープロバイダーを使用できます。

手順

  1. メニューで Identity Providers をクリックします。

    ID プロバイダー

    Identity Providers

  2. Add provider リストから、追加するアイデンティティープロバイダーを選択します。Red Hat Single Sign-On は、選択したアイデンティティープロバイダーの設定ページを表示します。

    Facebook アイデンティティープロバイダーの追加

    Add Facebook Identity Provider

    アイデンティティープロバイダーを設定すると、オプションとして Red Hat Single Sign-On ログインページに表示されます。各アイデンティティープロバイダーについて、ログイン画面にカスタムアイコンを配置することができます。詳細は、custom icons を参照してください。

    IDP ログインページ

    identity provider login page

    ソーシャル
    ソーシャルプロバイダーを使用すると、レルムでソーシャル認証を有効にできます。Red Hat Single Sign-On を使用すると、ユーザーはソーシャルネットワークアカウントを使用してアプリケーションにログインすることができます。サポートされるプロバイダーには、Twitter、Facebook、Google、LinkedIn、Instagram、Microsoft、PayPal、Openshift v3、GitHub、GitLab、Bitbucket、および Stack Overflow が含まれます。
    プロトコルベース
    プロトコルベースのプロバイダーは、ユーザーの認証および承認を特定のプロトコルに依存します。これらのプロバイダーを使用して、特定のプロトコルに準拠する任意のアイデンティティープロバイダーに接続できます。Red Hat Single Sign-On は、SAML v2.0 プロトコルおよび OpenID Connect v1.0 プロトコルのサポートを提供します。これらのオープン標準に基づいて、任意のアイデンティティープロバイダーを設定し、ブローカーを設定できます。

それぞれの種類のアイデンティティープロバイダーにはその設定オプションがありますが、設定の一部はすべてに共通です。以下の設定オプションが利用できます。

表9.1 共通の設定

設定説明

Alias

エイリアスは、アイデンティティープロバイダーの一意の識別子で、内部アイデンティティープロバイダーを参照します。Red Hat Single Sign-On は、エイリアスを使用してOpenID Connect プロトコルのリダイレクト URI を構築します。これらのプロトコルには、アイデンティティープロバイダーと通信するためのリダイレクト URI またはコールバック URL が必要です。すべてのアイデンティティープロバイダーにはエイリアスが必要です。エイリアスの例には facebookgoogle、および idp.acme.com などがあります。

Enabled

プロバイダーのオン/オフを切り替えます。

Hide on Login Page

ON の場合、Red Hat Single Sign-On は、ログインページにログインオプションとしてこのプロバイダーを表示しません。クライアントがこのプロバイダーを要求するには、URL の 'kc_idp_hint' パラメーターを使用してログインを要求します。

Account Linking Only

ON の場合、Red Hat Single Sign-On は既存のアカウントをこのプロバイダーとリンクします。このプロバイダーはユーザーをログインできず、Red Hat Single Sign-On では、ログインページにオプションとしてこのプロバイダーは表示されません。

Store Tokens

ON の場合、Red Hat Single Sign-On はアイデンティティープロバイダーからトークンを保存します。

Stored Tokens Readable

ON の場合、ユーザーは保存されたアイデンティティープロバイダートークンを取得できます。このアクションは、broker クライアントレベルのロールの read token にも適用されます。

Trust Email

ON の場合、Red Hat Single Sign-On はアイデンティティープロバイダーからのメールアドレスを信頼します。レルムがメール検証を要求する場合は、このアイデンティティープロバイダーからログインするユーザーは、メールの検証プロセスを実行する必要はありません。

GUI Order

利用可能なアイデンティティープロバイダーの、ログインページでの並べ替え順序。

First Login Flow

ユーザーがこのアイデンティティープロバイダーを使用して初めて Red Hat Single Sign-On にログインする際に、Red Hat Single Sign-On がトリガーする認証フロー。

Post Login Flow

ユーザーが外部アイデンティティープロバイダーを使用したログインを終了した際に、Red Hat Single Sign-On がトリガーする認証フロー。

Sync Mode

マッパーを通じて、アイデンティティープロバイダーからのユーザー情報を更新するストラテジー。legacy を選択する場合、Red Hat Single Sign-On は現在の動作を使用していました。Import の場合はユーザーデータを更新せず、forceの場合は、可能であればユーザーデータを更新します。詳細は、「アイデンティティープロバイダーマッパー」を参照してください。

9.4. ソーシャルアイデンティティープロバイダー

ソーシャルアイデンティティープロバイダーは、認証を信頼できるソーシャルメディアアカウントに委譲できます。Red Hat Single Sign-On には、Google、Facebook、Twitter、GitHub、LinkedIn、Microsoft、Stack Overflow などのソーシャルネットワークのサポートが含まれます。

9.4.1. Bitbucket

Bitbucket でログインするには、以下の手順を実行します。

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider 一覧から Bitbucket を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで、Bitbucket Cloud での OAuth のプロセスを実行します。Add Consumer をクリックする際に、

    1. Redirect URI の値を Callback URL フィールドに貼り付けます。
    2. Account セクションで Email および Read を選択し、アプリケーションが電子メールを読み取れるようにします。
  5. コンシューマーの作成時にBitbucket が表示するKey および Secret の値を書き留めておきます。
  6. Red Hat Single Sign-On で、Key の値を Client ID フィールドに貼り付けます。
  7. Red Hat Single Sign-On で、Secret の値を Client Secret フィールドに貼り付けます。
  8. Save をクリックします。

9.4.2. Facebook

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから Facebook を選択します。Red Hat Single Sign-On は、Facebookアイデンティティープロバイダーの設定ページを表示します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで、Facebook 開発者ガイド の手順に従って、Facebook でプロジェクトとクライアントを作成します。

    1. アプリケーションが Web サイトタイプのアプリケーションであることを確認します。
    2. Facebook Website 設定ブロックの Site URLRedirect URI の値を入力します。
    3. アプリケーションがパブリックであることを確認します。
  5. Facebook アプリケーションの Client ID および Client Secret の値を、Red Hat Single Sign-On の Client ID フィールドおよび Client Secret フィールドに入力します。
  6. 必要なスコープを Default Scopes フィールドに入力します。デフォルトでは、Red Hat Single Sign-On は email スコープを使用します。Facebook スコープの詳細については、「グラフAPI」を参照してください。

デフォルトでは、Red Hat Single Sign-On は profile 要求をgraph.facebook.com/me?fields=id,name,email,first_name,last_name に送信します。応答には、id、name、email、first_name、および last_name フィールドのみが含まれます。Facebook プロファイルから追加のフィールドを取得するには、対応するスコープを追加し、Additional user’s profile fields 設定オプションフィールドにフィールド名を追加します。

9.4.3. GitHub

Github でログインするには、以下の手順を実行します。

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから Github を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで OAUTH アプリケーションを作成します

    1. アプリケーションの作成時に、Redirect URI の値を Authorization callback URL フィールドに入力します。
    2. OAUTH アプリケーションの管理ページの Client ID および Client シークレットをメモします。
  5. Red Hat Single Sign-On で、Client ID の値を Client ID フィールドに貼り付けます。
  6. Red Hat Single Sign-On で、Client Secret の値を Client Secret フィールドに貼り付けます。
  7. Save をクリックします。

9.4.4. GitLab

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから GitLab を選択します。

    アイデンティティープロバイダーの追加

    Add identity provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで、新しい GitLab アプリケーションを追加します

    1. クリップボードの Redirect URIRedirect URI として使用します。
    2. アプリケーションを保存する際に Client ID および Client Secret をメモします。
  5. Red Hat Single Sign-On で、Client ID の値を Client ID フィールドに貼り付けます。
  6. Red Hat Single Sign-On で、Client Secret の値を Client Secret フィールドに貼り付けます。
  7. Save をクリックします。

9.4.5. Google

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから Google を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. 別のブラウザータブで、GoogleCloudPlatform コンソール 開きます。
  4. Google アプリケーションの Google ダッシュボードで、OAuth consent screen メニューをクリックします。同意画面を作成し、合意画面のユーザータイプが外部であることを確認します。
  5. Google ダッシュボードで以下を行います。

    1. Credentials メニューをクリックします。
    2. CREATE CREDENTIALS - OAuth Client ID をクリックします。
    3. Application type リストから Web application を選択します。
    4. Create をクリックします。
    5. Your Client ID とクライアント Your Client Secret を書き留めます。
  6. Red Hat Single Sign-On で、Your Client ID の値を Client ID フィールドに貼り付けます。
  7. Red Hat Single Sign-On で、Your Client Secretの値を Client Secret フィールドに貼り付けます。
  8. 必要なスコープを Default Scopes フィールドに入力します。デフォルトでは、Red Hat Single Sign-On は openidprofileemail のスコープを使用します。Google スコープの一覧については、「OAuth Playground」を参照してください。
  9. アクセスをGSuite 組織のメンバーのみに制限するには、Hosted Domain フィールドに G Suite ドメインを入力します。
  10. Save をクリックします。

9.4.6. LinkedIn

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから LinkedIn を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで、アプリケーションを作成します

    1. アプリケーションの作成後に、Auth タブをクリックします。
    2. Redirect URI の値を Authorized redirect URLs for your app フィールドに入力します。
    3. Your Client ID とクライアント Your Client Secret を書き留めます。
  5. Red Hat Single Sign-On で、Client ID の値を Client ID フィールドに貼り付けます。
  6. Red Hat Single Sign-On で、Client Secret の値を Client Secret フィールドに貼り付けます。
  7. Save をクリックします。

9.4.7. Microsoft

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから Microsoft を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで Microsoft アプリケーションを作成します

    1. Add URL をクリックして、Microsoft アプリケーションへのリダイレクト URL を追加します。
    2. Application IDApplication Secret をメモします。
  5. Red Hat Single Sign-On で、Application ID の値を Client ID フィールドに貼り付けます。
  6. Red Hat Single Sign-On で、Application Secret の値を Client Secret フィールドに貼り付けます。
  7. Save をクリックします。

9.4.8. OpenShift 3

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから Openshift を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. oc コマンドラインツールを使用して、クライアントを登録します。

    $ oc create -f <(echo '
    kind: OAuthClient
    apiVersion: v1
    metadata:
     name: kc-client 1
    secret: "..." 2
    redirectURIs:
     - "http://www.example.com/" 3
    grantMethod: prompt 4
    ')
1
OAuth クライアントの 名前<openshift_master>/oauth/authorize および <openshift_master>/oauth/token への要求の実行時に client_id 要求パラメーターとして渡されます。
2
Red Hat Single Sign-On が client_secret リクエストパラメーターに使用するsecret
3
<openshift_master>/oauth/authorize および <openshift_master>/oauth/token への要求で指定される redirect_uri パラメーターは、redirectURIs のいずれかの URI と同じ (または接頭辞が付けられた) 必要があります。これは、Identity Provider 画面の Redirect URI フィールドから取得できます。
4
このクライアントがトークンを要求し、ユーザーがアクセスを付与していない場合に、Red Hat Single Sign-Onがアクションを判断するために使用するgrantMethod
  1. Red Hat Single Sign-On で、Client ID の値を Client ID フィールドに貼り付けます。
  2. Red Hat Single Sign-On で、Client Secret の値を Client Secret フィールドに貼り付けます。
  3. Save をクリックします。

9.4.9. OpenShift 4

前提条件

  1. jq のインストール
  2. コンテナーで設定され /var/run/secrets/kubernetes.io/serviceaccount/ca.crtに設定されたX509_CA_BUNDLE

手順

  1. コマンドラインで以下のコマンドを実行し、OpenShift 4 API URL の出力を書き留めます。

    curl -s -k -H "Authorization: Bearer $(oc whoami -t)" \https://<openshift-user-facing-api-url>/apis/config.openshift.io/v1/infrastructures/cluster | jq ".status.apiServerURL"
  2. Red Hat Single Sign-On メニューで Identity Providers をクリックします。
  3. Add provider リストから Openshift を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  4. Redirect URI の値をクリップボードにコピーします。
  5. oc コマンドラインツールを使用して、クライアントを登録します。

    $ oc create -f <(echo '
    kind: OAuthClient
    apiVersion: oauth.openshift.io/v1
    metadata:
     name: keycloak-broker 1
    secret: "..." 2
    redirectURIs:
     - "<copy pasted Redirect URI from OpenShift 4 Identity Providers page>" 3
    grantMethod: prompt 4
    ')
1
OAuth クライアントの 名前<openshift_master>/oauth/authorize および <openshift_master>/oauth/token への要求の実行時に client_id 要求パラメーターとして渡されます。name パラメーターは、OAuthClient オブジェクトと Red Hat Single Sign-On 設定で同じである必要があります。
2
Red Hat Single Sign-On が client_secret リクエストパラメーターとして使用するsecret
3
<openshift_master>/oauth/authorize および <openshift_master>/oauth/token への要求で指定される redirect_uri パラメーターは、redirectURIs のいずれかの URI と同じ (または接頭辞が付けられた) 必要があります。これを正しく設定する最も簡単な方法は、Red Hat Single Sign-On OpenShift 4 Identity Provider 設定ページから (Redirect URI フィールド) コピーすることです。
4
このクライアントがトークンを要求し、ユーザーがアクセスを付与していない場合に、Red Hat Single Sign-Onがアクションを判断するために使用するgrantMethod
  1. Red Hat Single Sign-On で、Client ID の値を Client ID フィールドに貼り付けます。
  2. Red Hat Single Sign-On で、Client Secret の値を Client Secret フィールドに貼り付けます。
  3. Save をクリックします。

詳細は、公式の OpenShift ドキュメント を参照してください。

9.4.10. PayPal

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから PayPal を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで、PayPal 開発者アプリケーションエリア を開きます。

    1. Create App をクリックして PayPal アプリケーションを作成します。
    2. Client ID と Client Secretを書き留めます。Show のリンクをクリックしてシークレットを表示します。
    3. Connect with PayPal のチェックボックスがオンになっていることを確認します。
    4. Return URL フィールドの値を、Red Hat Single Sign-On の Redirect URI の値に設定します。
  5. Red Hat Single Sign-On で、Client ID の値を Client ID フィールドに貼り付けます。
  6. Red Hat Single Sign-On で、Client Secret の値を Client Secret フィールドに貼り付けます。
  7. Save をクリックします。

9.4.11. Stack overflow

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから Stack Overflow を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. 別のブラウザータブで、Stack Apps でのアプリケーションの登録 にログインします。

    アプリケーションの登録

    Register Application

    1. Application Name フィールドにアプリケーション名を入力します。
    2. OAuth domain フィールドに OAuth ドメインを入力します。
    3. Register Your Application をクリックします。

      設定

      Settings

  4. Client IDClient Secretを書き留めます。
  5. Red Hat Single Sign-On で、Client ID の値を Client ID フィールドに貼り付けます。
  6. Red Hat Single Sign-On で、Client Secret の値を Client Secret フィールドに貼り付けます。
  7. Save をクリックします。

9.4.12. Twitter

前提条件

  1. Twitter 開発者アカウント。

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから Twitter を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで、Twitter Application Management でアプリケーションを作成します。

    1. 名前および説明には、任意の値を入力します。
    2. Website の値は、localhost 以外の有効な URL にすることができます。
    3. Redirect URL の値を Callback URL フィールドに貼り付けます。
    4. Twitter アプリケーションの作成時に、Keys and Access Tokens セクションの Consumer Key および Consumer Secret の値をメモします。
  5. Red Hat Single Sign-On で、Consumer Key の値を Client ID フィールドに貼り付けます。
  6. Red Hat Single Sign-On で、Consumer Secret の値を Client Secret フィールドに貼り付けます。
  7. Save をクリックします。

9.4.13. Instagram

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから Instagram を選択します。Red Hat Single Sign-On は、Instagram アイデンティティープロバイダーの設定ページを表示します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. Redirect URI の値をクリップボードにコピーします。
  4. 別のブラウザータブで、Facebook 開発者コンソール を開きます。

    1. My Apps をクリックします。
    2. Add a New App を選択します。

      新規アプリケーションの追加

      Add a New App

    3. For Everything Else を選択します。

      新規アプリケーション ID を作成します。

      instagram create app id

    4. すべての必須フィールドに入力します。
    5. Create App をクリックします。ダッシュボードに移動します。
    6. ナビゲーションパネルで Settings - Basic を選択します。

      プラットフォームの追加

      Add Platform

    7. + Add Platform を選択します。
    8. [Website] をクリックします。
    9. サイトの URL を入力します。

      製品の追加

      instagram add product

    10. メニューから Dashboard を選択します。
    11. Instagram ボックスで Set Up をクリックします。
    12. メニューから Instagram - Basic Display を選択します。
    13. Create New App をクリックします。

      新しい Instagram アプリケーション ID を作成します。

      Create a New Instagram App ID

    14. Display Name に値を入力します。

      アプリケーションのセットアップ

      Setup the App

    15. Red Hat Single Sign-On の Redirect URLValid OAuth Redirect URIs フィールドに貼り付けます。
    16. Red Hat Single Sign-On の Redirect URLValid Deauthorize Callback URL フィールドに貼り付けます。
    17. Red Hat Single Sign-On の Redirect URLValid Data Deletion Request URL フィールドに貼り付けます。
    18. Instagram App Secret フィールドで Show をクリックします。
    19. Instagram App IDInstagram App Secret をメモします。
    20. App Review - Requests をクリックします。
    21. 画面の指示に従ってください。
  5. Red Hat Single Sign-On で、Instagram App ID の値を Client ID フィールドに貼り付けます。
  6. Red Hat Single Sign-On で、Instagram App Secret の値を Client Secret フィールドに貼り付けます。
  7. Save をクリックします。

9.5. OpenID Connect v1.0 アイデンティティープロバイダー

Red Hat Single Sign-On は、OpenID Connect プロトコルに基づいてアイデンティティープロバイダーのブローカーとして機能します。ユーザーを認証しアクセスを承認するには、これらのアイデンティティープロバイダー (IDP) は、仕様によって定義された Authorization Code Flow をサポートする必要があります。

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから OpenID Connect v1.0 を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. 初期設定オプションを入力します。設定オプションの詳細は、「一般的な IDP 設定」を参照してください。

    表9.2 OpenID の接続設定

    設定説明

    Authorization URL

    OIDC プロトコルが要求する承認 URL エンドポイント。

    Token URL

    OIDC プロトコルが要求するトークン URL エンドポイント。

    Logout URL

    OIDC プロトコルのログアウト URL エンドポイント。この値はオプションです。

    Backchannel Logout

    ユーザーをログアウトするための、IDP へのバックグラウンド (アウトオブバウンド) REST リクエスト。一部の IDP は、ブラウザークッキーを使用してセッションを認識するため、ブラウザーリダイレクトによってしかログアウトを実行しません。

    User Info URL

    OIDC プロトコルが定義するエンドポイント。このエンドポイントは、ユーザープロファイル情報を参照します。

    Client Authentication

    Red Hat Single Sign-On が Authorization Code Flow で使用するクライアント認証メソッドを定義します。秘密鍵で署名された JWT の場合、Red Hat Single Sign-On はレルムの秘密鍵を使用します。他の場合は、クライアントシークレットを定義します。詳細は、クライアント認証の仕様 を参照してください。

    Client ID

    外部 IDP への OIDC クライアントとして動作するレルム。認証コードフローを使用して外部 IDP と対話する場合は、レルムに OIDC クライアント ID が必要です。

    Client Secret

    外部 vault からのクライアントシークレット。このシークレットは、Authorization Code Flow を使用している場合は必要になります。

    Client Assertion Signature Algorithm

    クライアント認証として JWT アサーションを作成する署名アルゴリズム。秘密鍵で署名した JWT または jwt としてのクライアントシークレットの場合、必要になります。アルゴリズムを指定しないと、以下のアルゴリズムが適合されます。RS256 は、秘密鍵で署名した JWT の場合に適合されます。HS256 は、jwt としてのクライアントシークレットの場合に適合されます。

    Issuer

    Red Hat Single Sign-On は、IDP からの応答で、この値に対して発行者の要求を検証します。

    Default Scopes

    Red Hat Single Sign-On が認証リクエストと共に送信する OIDC スコープの一覧。デフォルト値は openid です。各スコープはスペースで区切ります。

    Prompt

    OIDC 仕様の prompt パラメーター。このパラメーターを使用して、再認証およびその他のオプションを強制的に実行できます。詳細は、仕様を参照してください。

    Accepts prompt=none forward from client

    prompt=none クエリーパラメーターが含まれる転送された認証リクエストをIDP が受け入れるかどうかを指定します。レルムが prompt=none の認証リクエストを受信すると、レルムはユーザーが現在認証されているかを確認し、ユーザーがログインしていない場合は login_required エラーを返します。Red Hat Single Sign-On が認証リクエストのデフォルト IDP を決定する場合(kc_idp_hint クエリーパラメーターを使用するか、レルムのデフォルト IDP を持つ場合)、prompt=none の認証リクエストをデフォルトの IDP に転送することができます。デフォルトの IDP は、そこにユーザーの認証をチェックします。すべての IDP がprompt=noneのリクエストをサポートしているわけではないため、Red Hat Single Sign-On は、認証リクエストをリダイレクトする前に、このスイッチを使用してデフォルトの IDP がパラメーターをサポートすることを示します。

    ユーザーが IDP で認証されていない場合、クライアントは login_required エラーを受け取ります。ユーザーが IDP で認証されている場合は、Red Hat Single Sign-On がユーザーの対話を求める認証ページを表示する必要があると、クライアントは interaction_required エラーを受け取る場合があります。この認証には、必要なアクション (パスワードの変更など)、合意画面、first broker login フローまたは post broker login フローで表示が設定された画面が含まれます。

    Validate Signatures

    Red Hat Single Sign-On がこのIDPによって署名された外部 ID トークンの署名を検証するかどうかを指定します。ON の場合、Red Hat Single Sign-On は外部の OIDC IDP の公開鍵を知っている必要があります。パフォーマンス上の目的で、Red Hat Single Sign-On は外部の OIDC アイデンティティープロバイダーの公開鍵をキャッシュします。アイデンティティープロバイダーの秘密鍵が危険にさらされた場合は、キーを更新し、キーのキャッシュをクリアします。詳細は、「キャッシュの消去」セクションを参照してください。

    Use JWKS URL

    このスイッチは、Validate SignaturesON の場合に適用されます。Use JWKS URLON の場合、Red Hat Single Sign-On は IDP の公開鍵を JWKS URL からダウンロードします。アイデンティティープロバイダーが新しいキーペアを生成すると、新しいキーがダウンロードされます。OFF の場合、Red Hat Single Sign-On はデータベースからの公開鍵(または証明書)を使用します。そのため、IDP キーペアが変更された場合は、新しいキーを Red Hat Single Sign-On データベースにもインポートします。

    JWKS URL

    IDP JWK キーの場所をポイントする URL。詳細は、JWK の仕様 を参照してください。外部 Red Hat Single Sign-On を IDP として使用する場合、仲介された Red Hat Single Sign-On が http://broker-keycloak:8180 で実行されていて、そのレルムがtest の場合、http://broker-keycloak:8180/auth/realms/test/protocol/openid-connect/certs などの URL を使用できます。

    Validating Public Key

    Red Hat Single Sign-On が外部 IDP 署名の検証に使用する PEM 形式の公開鍵。このキーは、Use JWKS URLOFF の場合に適用されます。

    Validating Public Key Id

    この設定は、Use JWKS URLOFF の場合に適用されます。この設定は、公開鍵の ID を PEM 形式で指定します。キーからキー ID を計算する標準的な方法がないため、外部 アイデンティティープロバイダーは Red Hat Single Sign-On が使用するアルゴリズムとは異なるアルゴリズムを使用できます。このフィールドの値が指定されていない場合、Red Hat Single Sign-On は、外部 IDP によって送信されるキー ID に関係なく、すべてのリクエストに検証用の公開鍵を使用します。ON の場合、このフィールドの値がプロバイダーからの署名を検証するために Red Hat Single Sign-On によって使用されるキー ID となり、IDP によって指定されたキー ID と一致する必要があります。

OpenID Provider Metadata を参照する URL またはファイルを指定して、この設定データをすべてインポートできます。Red Hat Single Sign-On 外部 IDP に接続する場合は、<root>/auth/realms/{realm-name}/.well-known/openid-configuration から IDP 設定をインポートできます。このリンクは、IDP に関するメタデータを記述する JSON ドキュメントです。

9.6. SAML v2.0 アイデンティティープロバイダー

Red Hat Single Sign-On は、SAML v2.0 プロトコルに基づいてブローカーアイデンティティープロバイダーを使用できます。

手順

  1. メニューで Identity Providers をクリックします。
  2. Add provider リストから SAML v2.0 を選択します。

    アイデンティティープロバイダーの追加

    Add Identity Provider

  3. 初期設定オプションを入力します。設定オプションの詳細は、「一般的な IDP 設定」を参照してください。.SAML Config
設定説明

Service Provider Entity ID

リモートアイデンティティープロバイダーがこのサービスプロバイダーからのリクエストを識別するために使用する SAML エンティティー ID。デフォルトでは、この設定はレルムベース URL <root>/auth/realms/{realm-name} に設定されます。

ID プロバイダーエンティティー ID

受信した SAML アサーションの Issuer 要素を検証するために使用される SAML エンティティー ID。空の場合、発行者の検証は実行されません。SAML IDP が IDP エンティティー記述子を公開する場合、このフィールドの値はそこで指定されます。

Single Sign-On Service URL

認証プロセスを開始する SAML エンドポイント。SAML IDP が IDP エンティティー記述子を公開する場合、このフィールドの値はそこで指定されます。

Single Logout Service URL

SAML ログアウトエンドポイント。SAML IDP が IDP エンティティー記述子を公開する場合、このフィールドの値はそこで指定されます。

Backchannel Logout

SAML IDP がバックチャネルのログアウトに対応している場合は、このスイッチを ON に切り替えます。

NameID Policy Format

名前識別子の形式に対応する URI 参照。デフォルトでは、Red Hat Single Sign-On はこれを urn:oasis:names:tc:SAML:2.0:nameid-format:persistent に設定します。

Principal Type

外部ユーザー ID の特定および追跡に使用される SAML アサーションの一部を指定します。Subject NameID または SAML 属性のいずれかを指定できます (名前または分かりやすい名前のいずれか)。Subject NameID の値は、'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' NameID Policy Format の値と共に設定することはできません。

Principal Attribute

Principal Typeが空欄でない場合は、このフィールドで識別する属性の名前(「Attribute [Name]」)または分かりやすい名前(「Attribute [Friendly Name]」)を指定します。

Allow create

外部アイデンティティープロバイダーがプリンシパルを表す新しい識別子を作成するのを許可します。

HTTP-POST Binding Response

外部 IDP によって送信される SAML リクエストに応答する SAML バインディングを制御します。OFF の場合、Red Hat Single Sign-On は Redirect Binding を使用します。

HTTP-POST Binding for AuthnRequest

外部 IDP からの認証を要求するときに SAML バインディングを制御します。OFF の場合、Red Hat Single Sign-On は Redirect Binding を使用します。

Want AuthnRequests Signed

ON の場合、Red Hat Single Sign-On はレルムのキーペアを使用して、外部の SAML IDP に送信される要求に署名します。

Signature Algorithm

Want AuthnRequests SignedON の場合に、使用する署名アルゴリズム。

SAML Signature Key Name

POST バインディングを使用して送信される署名済み SAML ドキュメントには、KeyName 要素の署名キー ID が含まれます。これには、デフォルトでは Red Hat Single Sign-On キー ID が含まれます。外部 SAML IDP には異なるキー名が必要です。このスイッチは、KeyName に次のものが含まれるかどうかを制御します。* KEY_ID - キー ID* CERT_SUBJECT - レルムキーに対応する証明書からのサブジェクト。Microsoft Active Directory Federation Services には CERT_SUBJECT が必要です。* NONE - Red Hat Single Sign-On は、SAML メッセージからキー名のヒントを省略します。

Force Authentication

ユーザーがすでにログインしている場合でも、ユーザーは外部の IDP に認証情報を入力する必要があります。

Validate Signature

ON の場合、レルムには SAML リクエストおよびデジタル署名する外部 IDP からの応答が必要です。

Validating X509 Certificate

Red Hat Single Sign-On が SAML リクエストおよび外部 IDP からの応答の署名を検証するのに使用する公開証明書。

Sign Service Provider Metadata

ON の場合、Red Hat Single Sign-On はレルムのキーペアを使用して SAML サービスプロバイダーメタデータ記述子 に署名します。

Pass subject

Red Hat Single Sign-On が login_hint クエリーパラメーターを IDP に転送するかどうかを制御します。Red Hat Single Sign-On は、このフィールドの値を AuthnRequest の Subject の login_hint パラメーターに追加し、宛先プロバイダーがログインフォームを事前に入力できるようにします。

属性消費サービスインデックス

リモート IDP に要求する属性セットを識別します。Red Hat Single Sign-On は、ID プロバイダー設定でマップされた属性を自動生成された SP メタデータドキュメントに自動的に追加します。

サービス名を使用している属性

自動生成される SP メタデータドキュメントでアドバタイズされる属性セットの説明的な名前。

外部 IDP の SAML IDP エンティティー記述子をポイントする URL またはファイルを指定することで、すべての設定データをインポートできます。Red Hat Single Sign-On の外部 IDP に接続する場合は、URL <root>/auth/realms/{realm-name}/protocol/saml/descriptor から IDP 設定をインポートできます。このリンクは、IDP に関するメタデータを記述する XML ドキュメントです。接続先の外部 SAML IDP のエンティティー記述子をポイントする URL または XML ファイルを指定することで、このすべての設定データをインポートすることもできます。

9.6.1. 特定の AuthnContexts の要求

アイデンティティープロバイダーは、クライアントがユーザーアイデンティティーを検証する認証方法の制約を指定するのを容易にします。たとえば、MFA、Kerberos 認証、またはセキュリティー要件を要求します。これらの制約は、特定の AuthnContext 条件を使用します。クライアントは 1 つまたは複数の条件を要求し、アイデンティティープロバイダーがどの程度要求された AuthnContext と一致しなければならないか(完全に、または他の同等の条件を満たしながら)を指定できます。

Requested AuthnContext Constraints セクションの ClassRefs または DeclRefs を追加して、サービスプロバイダーが必要とする条件を一覧にして設定できます。通常、ClassRefs または DeclRefs のいずれかを指定する必要があるため、どの値がサポートされるかをアイデンティティープロバイダーのドキュメントで確認してください。ClassRefs または DeclRefs が存在しない場合、アイデンティティープロバイダーは追加の制約を適用しません。

表9.3 要求される AuthnContext 制約

設定Description

Comparison

アイデンティティープロバイダーがコンテキスト要件を評価するために使用する方法。設定可能な値は、ExactMinimumMaximum、または Better です。デフォルト値は Exact です。

AuthnContext ClassRefs

必要な基準を記述する AuthnContext ClassRefs。

AuthnContext DeclRefs

必要な基準を記述する AuthnContext DeclRefs。

9.6.2. SP 記述子

プロバイダーの SAML SP メタデータにアクセスする場合は、アイデンティティープロバイダー設定で Endpoints 項目を探します。これには、サービスプロバイダーの SAML エンティティー記述子を生成する SAML 2.0 Service Provider Metadata のリンクが含まれます。記述子をダウンロードするか、またはその URL をコピーして、それをリモートの ID プロバイダーにインポートすることができます。

このメタデータは、以下の URL で一般に公開されています。

http[s]://{host:port}/auth/realms/{realm-name}/broker/{broker-alias}/endpoint/descriptor

記述子にアクセスする前に設定変更を保存するようにしてください。

9.6.3. SAML リクエストのサブジェクトの送信

デフォルトでは、SAML アイデンティティープロバイダーをポイントするソーシャルボタンは、ユーザーを以下のログイン URL にリダイレクトします。

http[s]://{host:port}/auth/realms/${realm-name}/broker/{broker-alias}/login

この URL に login_hint という名前のクエリーパラメーターを追加すると、パラメーターの値が Subject 属性として SAML リクエストに追加されます。このクエリーパラメーターが空欄の場合、Red Hat Single Sign-On はサブジェクトをリクエストに追加しません。

「Pass subject」オプションを有効にして SAML リクエストのサブジェクトを送信します。

9.7. クライアント提案されたアイデンティティープロバイダー

OIDC アプリケーションは、使用するアイデンティティープロバイダーのヒントを指定することで、Red Hat Single Sign-On ログインページをバイパスできます。これを有効にするには、Authorization Code Flow 承認エンドポイントに kc_idp_hint クエリーパラメーターを設定します。

Red Hat Single Sign-On OIDC クライアントアダプターを使用すると、アプリケーションのセキュアなリソースにアクセスする際に、このクエリーパラメーターを指定できます。

以下に例を示します。

GET /myapplication.com?kc_idp_hint=facebook HTTP/1.1
Host: localhost:8080

この場合、レルムには facebook エイリアスを持つアイデンティティープロバイダーが必要です。このプロバイダーが存在しない場合は、ログインフォームが表示されます。

keycloak.js アダプターを使用している場合は、以下のように同じ動作を得ることもできます。

const keycloak = new Keycloak('keycloak.json');

keycloak.createLoginUrl({
	idpHint: 'facebook'
});

kc_idp_hint クエリーパラメーターを使用すると、Identity Provider Redirector オーセンティケーターにアイデンティティープロバイダーを設定した場合、クライアントはデフォルトのプロバイダーを上書きできます。kc_idp_hint クエリーパラメーターを空値に設定すると、クライアントは自動リダイレクトを無効にできます。

9.8. クレームとアサーションのマッピング

認証する外部 IDP が提供する SAML および OpenID Connect メタデータを、レルムにインポートできます。インポート後に、ユーザープロファイルのメタデータやその他の情報を抽出でき、アプリケーションが利用できるようにすることができます。

外部アイデンティティープロバイダー経由でレルムにログインする各ユーザーには、SAML または OIDC アサーションおよび要求からのメタデータに基づいて、ローカルの Red Hat Single Sign-On データベースにエントリーを持ちます。

手順

  1. メニューで Identity Providers をクリックします。
  2. 一覧でアイデンティティープロバイダーを 1 つ選択します。
  3. Mappers タブをクリックします。

    アイデンティティープロバイダーマッパー

    identity provider mappers

  4. Create をクリックします。

    アイデンティティープロバイダーマッパー

    identity provider mapper

  5. Sync Mode Override の値を選択します。マッパーは、この設定に従ってユーザーが繰り返しログインする際に、ユーザー情報を更新します。

    1. 以前の Red Hat Single Sign-On バージョンの動作を使用するには、legacy を選択します。
    2. 特定のアイデンティティープロバイダーを使用した Red Hat Single Sign-On への初回ログイン時に、ユーザーが Red Hat Single Sign-On に初めて作成された際にデータをインポートするには、import を選択してします。
    3. 各ユーザーログイン時にユーザーデーターを更新するには、force を選択します。
    4. アイデンティティープロバイダーで設定された同期モードを使用するには、inherit を選択します。その他のオプションはすべて、この同期モードを上書きします。
  6. Mapper Type リストからマッパーを選択します。Mapper Type にカーソルを合わせ、マッパーの説明とマッパーに入力する設定を確認します。
  7. Save をクリックします。

JSON ベースの要求では、ドット表記を使用して、インデックスでアレイフィールドにアクセスするため、ネスト化と角括弧を使用します。たとえば、contact.address[0].country です。

ソーシャルプロバイダーが提供するユーザープロファイル JSON データの構造を調べるには、サーバーの app-server 設定ファイル(domain.xml または standalone.xml)でDEBUG レベルのロガー org.keycloak.social.user_profile_dump を有効にします。

9.9. 利用可能なユーザーセッションデータ

外部 IDP からユーザーがログインした後、Red Hat Single Sign-On は、アクセス可能なユーザーセッションノートデータを保存します。このデータは、適切なクライアントマッパーを使用してクライアントに渡されるトークンまたは SAML アサーションを介してログインを要求するクライアントに反映できます。

identity_provider
ログインの実行に使用されるブローカーの IDP エイリアス。
identity_provider_identity
現在認証されているユーザーの IDP ユーザー名。多くの場合、Red Hat Single Sign-On のユーザー名と同じです。ただし、そうでない場合もあります。たとえば、Red Hat Single Sign-On は、ユーザー john を Facebook ユーザー john123@gmail.com とリンクできます。この場合、ユーザーセッションノートの値は john123@gmail.com です。

User Session Note 型のプロトコルマッパーを使用して 、この情報をクライアントに伝播することに注意してください。

9.10. First Login Flow

ユーザーがアイデンティティー仲介を使用してログインすると、Red Hat Single Sign-On はレルムのローカルデータベース内のユーザーの要素をインポートし、リンクします。Red Hat Single Sign-On が外部アイデンティティープロバイダーを介してユーザーを正常に認証すると、以下の 2 つの状況が発生する可能性があります。

  • Red Hat Single Sign-On は、すでにユーザーアカウントをインポートし、認証されたアイデンティティープロバイダーアカウントにリンクしている。この場合、Red Hat Single Sign-On は既存のユーザーとして認証を行い、アプリケーションにリダイレクトします。
  • Red Hat Single Sign-On には、このユーザーのアカウントが存在しない。通常、新しいアカウントを登録して Red Hat Single Sign-On データベースにインポートしますが、同じメールアドレスを持つ既存の Red Hat Single Sign-On アカウントが存在する可能性があります。既存のローカルアカウントを外部アイデンティティープロバイダーに自動的にリンクすることは、セキュリティーホールとなる可能性があります。外部アイデンティティープロバイダーから取得する情報を常に信頼することはできません。

このような状況に対処する場合、組織ごとに異なる要件があります。Red Hat Single Sign-On では、IDP 設定で First Login Flow オプションを使用して、外部 IDP からのユーザーの初回ログインに workflow を選択できます。デフォルトでは、First Login Flow オプションは first broker login フローをポイントしますが、独自のフローを使用することや、アイデンティティープロバイダーごとに異なるフローを使用することができます。

フローは管理コンソールの Authentication タブにあります。First Broker Login フローを選択すると、デフォルトで使用されるオーセンティケーターが表示されます。既存のフローを再構成できます。たとえば、一部のオーセンティケーターを無効にすることや、一部をrequired と識別することや、一部のオーセンティケーターを設定することができます。

9.10.1. デフォルトのfirst login flowのオーセンティケーター

プロファイルの確認
  • このオーセンティケーターはプロファイル情報ページを表示するため、ユーザーは Red Hat Single Sign-On がアイデンティティープロバイダーから取得するプロファイルを確認することができます。
  • Actions メニューで Update Profile On First Login オプションを設定できます。
  • ON の場合、ユーザーにはプロファイルページが表示され、ユーザーのアイデンティティーのフェデレーションを行うために追加情報が要求されます。
  • missing 場合、アイデンティティープロバイダーがメール、名、姓などの必須情報を提供しない場合、ユーザーにはプロファイルページが表示されます。
  • OFF の場合、ユーザーが後でConfirm Link Existing Account オーセンティケーターによって表示されるページの Review profile info リンクをクリックしない限り、プロファイルページは表示されません。
Create User If Unique

このオーセンティケーターは、アイデンティティープロバイダーからのアカウントと同じメールまたはユーザー名を持つ既存の Red Hat Single Sign-On アカウントがすでにあるかどうかを確認します。ない場合は、オーセンティケーターは新しいローカルの Red Hat Single Sign-On アカウントを作成し、それをアイデンティティープロバイダーとリンクし、フロー全体を終了します。それ以外の場合は、次の Handle Existing Account サブフローが処理されます。重複アカウントがないことを確認する場合は、このオーセンティケーターを REQUIRED とマークできます。この場合、既存の Red Hat Single Sign-On アカウントがある場合、ユーザーはアカウント管理でアイデンティティープロバイダーアカウントをリンクする必要がある場合に、エラーページが表示されます。

  • このオーセンティケーターは、アイデンティティープロバイダーのアカウントと同じメールまたはユーザー名を持つ Red Hat Single Sign-On アカウントがすでにあることを確認します。
  • アカウントが存在しない場合は、オーセンティケーターはローカルの Red Hat Single Sign-On アカウントを作成し、このアカウントをアイデンティティープロバイダーとリンクさせ、フローを終了します。
  • アカウントが存在する場合、オーセンティケーターは次の Handle Existing Account サブフローを実装します。
  • 重複アカウントがないようにするには、このオーセンティケーターを REQUIRED とマークします。Red Hat Single Sign-On アカウントが存在する場合、ユーザーにはエラーページが表示され、ユーザーは Account 管理を通じてアイデンティティープロバイダーアカウントをリンクする必要があります。
既存のアカウントのリンクの確認
  • 情報ページで、同じメールの Red Hat Single Sign-On アカウントが表示されます。ユーザーはプロファイルを再度確認し、別の電子メールまたはユーザー名を使用できます。フローが再起動され、Review Profile オーセンティケーターに戻ります。
  • あるいは、ユーザーはアイデンティティープロバイダーアカウントを既存の Red Hat Single Sign-On アカウントにリンクすることを確認できます。
  • ユーザーにこの確認ページを表示させず、直接メール検証または再認証によりアイデンティティープロバイダーのアカウントをリンクさせるには、このオーセンティケーターを無効にします。
既存のアカウントをメールで検証
  • このオーセンティケーターは、デフォルトで ALTERNATIVE です。レルムに SMTP 設定が設定されている場合、Red Hat Single Sign-On はこのオーセンティケーターを使用します。
  • オーセンティケーターはユーザーにメールを送信し、アイデンティティープロバイダーを Red Hat Single Sign-On アカウントにリンクすることを確認します。
  • メールによるリンクを確認せず、ユーザーをそのパスワード で再認証する方が望ましい場合には、このオーセンティケーターを無効にします。
再認証による既存のアカウントの確認
  • メールオーセンティケーターが利用できない場合には、このオーセンティケーターを使用します。たとえば、レルムに SMTP を設定していない場合。このオーセンティケーターは、ユーザーが認証して Red Hat Single Sign-On アカウントをアイデンティティープロバイダーにリンクするログイン画面を表示します。
  • ユーザーは、すでに Red Hat Single Sign-On アカウントにリンクされている別のアイデンティティープロバイダーで再認証することもできます。
  • ユーザーにOTP の使用を強制することができます。それ以外の場合は、任意で、ユーザーアカウントに OTP を設定した場合に使用されます。

9.10.3. 自動ユーザー作成の無効化

Defaultの最初のログインフローは、外部アイデンティティーに一致する Red Hat Single Sign-On アカウントを検索し、リンクをオファーします。一致する Red Hat Single Sign-On アカウントが存在しない場合は、フローが自動的に作成します。

このデフォルトの動作は、一部のセットアップでは適切ではない可能性があります。1 つの例は、すべてのユーザーが事前に作成されている、読み取り専用の LDAP ユーザーストアを使用する場合です。この場合は、自動ユーザー作成をオフにする必要があります。

ユーザーの作成を無効にするには、以下を実行します。

手順

  1. メニューで Authentication をクリックします。
  2. 一覧から First Broker Login を選択します。
  3. Create User if UniqueDISABLED に設定します。
  4. Confirm Link Existing AccountDISABLED に設定します。

また、この設定は、Red Hat Single Sign-On 自体が外部アイデンティティーに対応する内部アカウントを判別できないことを意味します。そのため、Verify Existing Account By Re-authentication オーセンティケーターにより、ユーザー名およびパスワードが提供されます。

9.10.4. 既存ユーザーの最初のログインフローの検出

以下の条件で、最初のログインフローを設定するには、

  • このレルムにすでに登録されているユーザーのみがログインできる。
  • ユーザーはプロンプトなしで自動的にリンクされる。

以下の 2 つのオーセンティケーターで新しいフローを作成します。

Detect Existing Broker User
このオーセンティケーターは、一意のユーザーが処理されるようにします。オーセンティケーターの要件を Mandatory に設定します。
Automatically Set Existing User
検証なしで既存のユーザーを認証コンテキストに自動的に設定します。オーセンティケーターの要件を Mandatory に設定します。

アイデンティティープロバイダー設定の First Login Flow をそのフローに設定する必要があります。ユーザープロファイル(姓、名 など)をアイデンティティープロバイダー属性で更新する場合は、Sync Modeforce に設定することもできます。

注記

このフローは、アイデンティティーを他のアイデンティティープロバイダー(github、Facebook など)に移譲するが、ログインできるユーザーを管理する場合に使用できます。

この設定では、Red Hat Single Sign-On は外部アイデンティティーに対応する内部アカウントを判断できません。Verify Existing Account By Re-authentication オーセンティケーターにより、プロバイダーにユーザー名とパスワードの入力が求められます。

9.11. 外部 IDP トークンの取得

Red Hat Single Sign-On を使用すると、IDP の設定ページで Store Token 設定オプションを使用して、外部 IDP との認証プロセスからのトークンと応答を保存できます。

アプリケーションコードは、これらのトークンと応答を取得し、追加のユーザー情報をインポートしたり、外部 IDP をを安全に要求したりすることができます。たとえば、アプリケーションは Google トークンを使用して他の Google サービスおよび REST API を使用できます。特定のアイデンティティープロバイダーのトークンを取得するには、以下のようにリクエストを送信します。

GET /auth/realms/{realm}/broker/{provider_alias}/token HTTP/1.1
Host: localhost:8080
Authorization: Bearer <KEYCLOAK ACCESS TOKEN>

アプリケーションは Red Hat Single Sign-On で認証し、アクセストークンを受け取る必要があります。このアクセストークンには broker クライアントレベルのロール read-token が設定されている必要があるため、ユーザーにこのロールのロールマッピングが必要であり、クライアントアプリケーションにはそのスコープ内でそのロールが必要です。この場合、Red Hat Single Sign-On の保護されたサービスにアクセスするため、ユーザー認証時に Red Hat Single Sign-On が発行するアクセストークンを送信します。ブローカー設定ページで、Stored Tokens Readable スイッチを ON に設定して、このロールを新たにインポートされたユーザーに割り当てることができます。

これらの外部トークンは、プロバイダーを介して再度ログインするか、またはクライアントが開始したアカウントリンク API を使用して再確立できます。

9.12. アイデンティティーブローカーのログアウト

ログアウトする場合は、Red Hat Single Sign-On は、最初にログインするのに使用した外部アイデンティティープロバイダーにリクエストを送信し、このアイデンティティープロバイダーからユーザーをログアウトします。この動作を省略し、外部アイデンティティープロバイダーからのログアウトを回避することができます。詳細は、アダプターのログアウトドキュメント を参照してください。

第10章 SSO プロトコル

このセクションでは、認証プロトコル、Red Hat Single Sign-On 認証サーバー、および Red Hat Single Sign-On 認証サーバーでセキュア化されたアプリケーションがどのようにこれらのプロトコルと対話するかを説明します。

10.1. OpenID Connect

OpenID Connect (OIDC) は、OAuth 2.0 の拡張機能である認証プロトコルです。

OAuth 2.0 は承認プロトコルを構築するためのフレームワークで、不完全です。一方、OIDC は、Json Web Token (JWT)標準を使用する完全な認証および承認プロトコルです。JWT 標準は、アイデンティティートークンの JSON 形式を定義し、コンパクトで Web フレンドリーにデータをデジタル署名および暗号化する方法を定義しています。

通常、OIDC は 2 つのユースケースを実装します。最初のケースは、Red Hat Single Sign-On サーバーがユーザーを認証するように要求するアプリケーションです。ログインに成功すると、アプリケーションは ID トークンアクセストークン を受け取ります。ID トークン には、ユーザー名、電子メール、プロファイル情報などのユーザー情報が含まれています。レルムは、アクセス情報(ユーザーロールマッピングなど)が含まれるアクセストークン にデジタル署名します。アプリケーションは、この情報を使用してユーザーがアプリケーションでアクセスできるリソースを判断します。

2 つ目のユースケースは、リモートサービスにアクセスするクライアントです。

  • クライアントは Red Hat Single Sign-On から アクセストークン を要求し、ユーザーの代わりにリモートサービスを呼び出します。
  • Red Hat Single Sign-On はユーザーを認証し、ユーザーに要求元のクライアントにアクセスを付与することに同意するよう要求します。
  • クライアントは、レルムによってデジタル署名される アクセストークン を受け取ります。
  • クライアントは、アクセストークン を使用して、リモートサービスで REST 要求を行います。
  • リモート REST サービスは アクセストークン を抽出します。
  • リモート REST サービスは、トークンの署名を検証します。
  • リモート REST サービスは、トークン内のアクセス情報に基づいて、リクエストを処理するか拒否するかを決定します。

10.1.1. OIDC 認証フロー

OIDC には、複数のメソッド(またはフロー)があり、クライアントまたはアプリケーションがユーザーを認証し、アイデンティティー および アクセス トークンを受け取るために使用できます。このメソッドは、アクセスを要求するアプリケーションまたはクライアントのタイプによって異なります。

10.1.1.1. 認可コードフロー

認可コードフローはブラウザーベースのプロトコルで、ブラウザーベースのアプリケーションの認証および承認に適しています。ブラウザーのリダイレクトを使用してアイデンティティーおよびアクセストークンを取得します。

  1. ユーザーは、ブラウザーを使用してアプリケーションに接続します。アプリケーションは、ユーザーがアプリケーションにログインしていないことを検出します。
  2. アプリケーションは、認証のためにブラウザーを Red Hat Single Sign-On にリダイレクトします。
  3. アプリケーションは、コールバック URL をブラウザーリダイレクトのクエリーパラメーターとして渡します。Red Hat Single Sign-On は、認証に成功するとパラメーターを使用します。
  4. Red Hat Single Sign-On がユーザーを認証し、1 回限りの有効期間の短い一時的なコードを作成します。
  5. Red Hat Single Sign-On はコールバック URL を使用してアプリケーションにリダイレクトし、一時コードをコールバック URL のクエリーパラメーターとして追加します。
  6. アプリケーションは一時コードを抽出し、Red Hat Single Sign-On にバックグラウンド REST 呼び出しを行い、アイデンティティーアクセスリフレッシュ トークンのコードを交換します。再生攻撃を防止するため、一時コードは複数回使用できません。
注記

システムは、トークンが有効な間、そのトークンの盗難に対して脆弱です。セキュリティーおよびスケーラビリティーの理由から、アクセストークンは通常すぐに期限切れになるように設定されるため、後続のトークンリクエストは失敗します。トークンの有効期限が切れると、アプリケーションはログインプロトコルによって送信される追加の 更新 トークンを使用して新しいアクセストークンを取得できます。

機密性が要求される クライアントは、トークンの一時コードを交換する際にクライアントシークレットを提供します。パブリッククライアントは、クライアントシークレットの提供を要求されません。パブリック クライアントは、HTTPS が厳格に適用され、クライアントに登録されているリダイレクト URI が厳格に制御される場合に保護されます。HTML5/JavaScript クライアントは、クライアントシークレットを HTML5/JavaScript クライアントへ安全に送信する方法がないため、パブリック クライアントである必要があります。詳細は、「クライアントの管理」の章を参照してください。

Red Hat Single Sign-On は、Proof Key for Code Exchange 仕様もサポートします。

10.1.1.2. インプリシットフロー

インプリシットフローはブラウザーベースのプロトコルです。これは Authorization Code Flow と似ていますが、要求が少なく、更新トークンはありません。

注記

トークンがリダイレクト URI で送信されると、アクセス トークンがブラウザーの履歴に漏洩する可能性があります(以下を参照)。

また、このフローはクライアントに更新トークンを提供しません。したがって、アクセストークンの有効期限を長くするか、期限切れになったらユーザーを再認証する必要があります。

このフローの使用を推奨していません。このフローは OIDC および OAuth 2.0 仕様にあるためサポートされます。

このプロトコルは以下のように動作します。

  1. ユーザーは、ブラウザーを使用してアプリケーションに接続します。アプリケーションは、ユーザーがアプリケーションにログインしていないことを検出します。
  2. アプリケーションは、認証のためにブラウザーを Red Hat Single Sign-On にリダイレクトします。
  3. アプリケーションは、コールバック URL をブラウザーリダイレクトのクエリーパラメーターとして渡します。Red Hat Single Sign-On は、認証に成功するとクエリーパラメーターを使用します。
  4. Red Hat Single Sign-On はユーザーを認証し、identity および access トークンを作成します。Red Hat Single Sign-On はコールバック URL を使用してアプリケーションにリダイレクトし、さらにアイデンティティー および アクセストークンをコールバック URL のクエリーパラメーターとして追加します。
  5. アプリケーションはコールバック URL から identity および access トークンを抽出します。

10.1.1.3. リソースオーナーパスワードクレデンシャルの付与 (直接アクセスグラント)

Direct Access Grants は、ユーザーの代わりにトークンを取得するために REST クライアントによって使用されます。これは、以下の項目を含む HTTP POST リクエストです。

  • ユーザーの認証情報。認証情報はフォームパラメーターで送信されます。
  • クライアントの ID。
  • クライアントシークレット(機密性が要求されるクライアントの場合)。

HTTP 応答には、アイデンティティーアクセス、および 更新 トークンが含まれます。

10.1.1.4. クライアント認証情報の付与

Client Credentials Grant は、外部ユーザーの代わりに機能するトークンを取得するのではなく、クライアントに関連付けられたサービスアカウントのメタデータおよびパーミッションに基づいてトークンを作成します。Client Credentials Grants は REST クライアントによって使用されます。

詳細は、「サービスアカウント」の章を参照してください。

10.1.1.5. デバイス承認の付与

これは、入力機能が制限されているか、または適切なブラウザーがないインターネット接続デバイスで実行されているクライアントによって使用されます。以下は、プロトコルの概要です。

  1. アプリケーションは Red Hat Single Sign-On にデバイスコードとユーザーコードを要求します。Red Hat Single Sign-On は、デバイスコードとユーザーコードを作成します。Red Hat Single Sign-On は、デバイスコードおよびユーザーコードなどの応答をアプリケーションに返します。
  2. アプリケーションはユーザーにユーザーコードと検証 URI を提供します。ユーザーは検証 URI にアクセスし、別のブラウザーを使用して認証されます。
  3. アプリケーションは Red Hat Single Sign-On に繰り返しポーリングを行い、ユーザーがユーザー承認を完了たかどうかを確認します。ユーザー認証が完了すると、アプリケーションは アイデンティティーアクセス更新のトークンのデバイスコードを交換します。

10.1.1.6. クライアントが開始したバックチャネル認証の付与

この機能は、OAuth 2.0 の認証コード付与のように、ユーザーのブラウザーを介してリダイレクトせずに、OpenID プロバイダーと直接通信することで認証フローを開始するクライアントによって使用されます。以下は、プロトコルの概要です。

  1. クライアントは、クライアントによる認証要求を識別する auth_req_id を Red Hat Single Sign-On に要求します。Red Hat Single Sign-On は auth_req_id を作成します。
  2. この auth_req_id を受信した後、このクライアントは、ユーザーが認証されるまで、auth_req_id と引き換えに、Red Hat Single Sign-On からアクセストークン、更新トークン、および ID トークンを取得するために Red Hat Single Sign-On を繰り返しポーリングする必要があります。

管理者は、Client Initiated Backchannel Authentication (CIBA)関連の操作をレルムごとに CIBA ポリシー として設定できます。

また、『Securing Applications and Services Guide』のBackchannel Authentication Endpoint section および Client Initiated Backchannel Authentication Grant section など、Red Hat Single Sign-On ドキュメントの他の箇所も参照してください。

10.1.1.6.1. CIBA ポリシー

管理者は、Admin Console で以下の操作を実行します。

  • Authentication → CIBA Policy タブを開きます。
  • 項目を設定し、Save をクリックします。

設定可能な項目とその説明を以下に示します。

設定Description

Backchannel Token Delivery Mode

CD(Consumption Device)が認証結果および関連するトークンを取得する方法を指定します。「poll」、「ping」、および「push」の 3 つのモードがあります。Red Hat Single Sign-On は、「poll」のみをサポートします。デフォルトの設定は「poll」です。この設定は必須です。詳細は、CIBA 仕様 を参照してください。

Expires In

認証リクエストが受信されてからの「auth_req_id」の有効期限(秒単位)。デフォルト設定は 120 です。この設定は必須です。詳細は、CIBA 仕様 を参照してください。

Interval

CD (Consumption Device)がトークンエンドポイントへのポーリングリクエストを待機する必要がある間隔(秒単位)。デフォルト設定は 5 です。この設定はオプションです。詳細は、CIBA 仕様 を参照してください。

Authentication Requested User Hint

認証が要求されているエンドユーザーを識別する方法。デフォルト設定は「login_hint」です。「login_hint」、「login_hint_token」、および「id_token_hint」の 3 つのモードがあります。Red Hat Single Sign-On は「login_hint」のみをサポートします。この設定は必須です。詳細は、CIBA 仕様 を参照してください。

10.1.1.6.2. プロバイダー設定

CIBA 付与は以下 2 つのプロバイダーを使用します。

  1. Authentication Channel Provider:Red Hat Single Sign-On と、AD(認証デバイス)でユーザーを実際に認証するエンティティー間の通信を提供します。
  2. User Resolver Provider: クライアントが提供する情報から Red Hat Single Sign-On の UserModel を取得し、ユーザーを特定します。

Red Hat Single Sign-On には両方のデフォルトプロバイダーがあります。ただし、管理者は以下のようにAuthentication Channel Providerを設定する必要があります。

<spi name="ciba-auth-channel">
    <default-provider>ciba-http-auth-channel</default-provider>
    <provider name="ciba-http-auth-channel" enabled="true">
        <properties>
            <property name="httpAuthenticationChannelUri" value="https://backend.internal.example.com/auth"/>
        </properties>
    </provider>
</spi>

設定可能な項目とその説明を以下に示します。

設定Description

httpAuthenticationChannelUri

AD(認証デバイス)でユーザーを実際に認証するエンティティーの URI を指定します。

10.1.1.6.3. Authentication Channel Provider

CIBA 標準ドキュメントでは、AD によるユーザーの認証方法は指定されていません。したがって、製品の判断で実装される可能性があります。Red Hat Single Sign-On は、この認証を外部認証エンティティーに委譲します。認証エンティティーと通信するには、Red Hat Single Sign-On は Authentication Channel Provider を提供します。

Red Hat Single Sign-On の実装では、認証エンティティーが Red Hat Single Sign-On の管理者の制御下にあり、Red Hat Single Sign-On が認証エンティティーを信頼することを前提としています。Red Hat Single Sign-On の管理者が制御できない認証エンティティーを使用することは推奨されません。

Authentication Channel Providerは SPI プロバイダーとして提供され、Red Hat Single Sign-On のユーザーは環境を満たすために独自のプロバイダーを実装できます。Red Hat Single Sign-On は、HTTP を使用して認証エンティティーと通信する HTTP Authentication Channel Provider と呼ばれるデフォルトプロバイダーを提供します。

Red Hat Single Sign-On ユーザーのユーザーが HTTP Authentication Channel Providerを使用する場合は、以下の 2 つの部分で構成されるRed Hat Single Sign-On と認証エンティティーの契約を知っている必要があります。

認証委譲リクエスト/レスポンス
Red Hat Single Sign-On は認証リクエストを認証エンティティーに送信します。
認証結果通知/ACK
認証エンティティーは、認証の結果を Red Hat Single Sign-On に通知します。

認証委譲リクエスト/レスポンスは、以下のメッセージングで構成されます。

認証委譲リクエスト
リクエストは Red Hat Single Sign-On から認証エンティティーに送信され、AD によるユーザー認証を要求します。
POST [delegation_reception]
  • Headers
名前Description

Content-Type

application/json

メッセージのボディーは json 形式です。

承認

Bearer [token]

[token] は、認証エンティティーが認証の結果を Red Hat Single Sign-On に通知する場合に使用されます。

  • パラメーター
タイプ名前Description

パス

delegation_reception

委譲リクエストを受信するために認証エンティティーによって提供されるエンドポイント

  • ボディー
名前Description

login_hint

だれがAD で認証されるかを認証エンティティーに指示します。
デフォルトでは、ユーザーの「ユーザー名」です。
このフィールドは必須で、CIBA 標準ドキュメントで定義されています。

scope

これは、認証されたユーザーから認証エンティティーが合意を取得するスコープを示します。
このフィールドは必須で、CIBA 標準ドキュメントで定義されています。

is_consent_required

これは、認証エンティティーがスコープについて認証済みユーザーから合意を取得する必要があるかどうかを示します。
このフィールドは必須です。

binding_message

この値は、CD と AD 両方の UI に表示され、ユーザーがAD による認証が CD によってトリガーされることを認識できるようにします。
このフィールドはオプションで、CIBA 標準ドキュメントで定義されています。

acr_values

これは、CD からの要求元の Authentication Context Class Referenceを指示します。
このフィールドはオプションで、CIBA 標準ドキュメントで定義されています。

認証委譲応答

認証エンティティーから Red Hat Single Sign-On に応答が返され、認証エンティティーが Red Hat Single Sign-On から認証リクエストを受け取ったことを通知します。

  • 応答
HTTP ステータスコードDescription

201

認証委譲リクエストを受信したことを Red Hat Single Sign-On に通知します。

認証結果通知/ACK は以下のメッセージングで構成されます。

認証結果通知
認証エンティティーは、認証リクエストの結果を Red Hat Single Sign-On に送信します。
POST /auth/realms/[realm]/protocol/openid-connect/ext/ciba/auth/callback
  • Headers
名前Description

Content-Type

application/json

メッセージのボディーは json 形式です。

承認

Bearer [token]

[token] は、認証エンティティーが認証委譲リクエストで Red Hat Single Sign-On から受け取ったトークンである必要があります。

  • パラメーター
タイプ名前Description

パス

realm

レルム名

  • ボディー
名前Description

status

これは、AD によるユーザー認証の結果を示します。
以下のステータスのいずれかである必要があります。
SUCCEED: AD による認証が正常に完了しました。
UNAUTHORIZED: AD による認証が完了していません。
CANCELLED: AD による認証はユーザーによりキャンセルされています。

認証結果 ACK

Red Hat Single Sign-On から認証エンティティーに応答が返され、Red Hat Single Sign-On が認証エンティティーからADによるユーザー認証の結果を受け取ったことを通知します。

  • 応答
HTTP ステータスコードDescription

200

認証の結果の通知を受信したことを認証エンティティーに通知します。

10.1.1.6.4. User Resolver Provider

同じユーザーであっても、その表現は CD、Red Hat Single Sign-On、および認証エンティティーごとに異なる場合があります。

CD、Red Hat Single Sign-On、および認証エンティティーが同じユーザーを認識するために、この User Resolver Provider は独自のユーザー表現を3者の間で変換します。

User Resolver Providerは SPI プロバイダーとして提供され、Red Hat Single Sign-On のユーザーは環境を満たすために独自のプロバイダーを実装できます。Red Hat Single Sign-On は、以下の特性を持つ Default User Resolver Provider と呼ばれるデフォルトプロバイダーを提供します。

  • login_hint パラメーターのみをサポートし、デフォルトとして使用されます。
  • Red Hat Single Sign-On の UserModel のusername は、CD、Red Hat Single Sign-On、および認証エンティティーのユーザーを表すために使用されます。

10.1.2. OIDC ログアウト

OIDC には、ログアウトメカニズムに関連する 4 つの仕様があります。これらの仕様は、ドラフトのステータスになります。

繰り返しになりますが、これらはすべて OIDC 仕様に記載されていますが、ここでは概要のみを説明します。

10.1.2.1. セッション管理

これはブラウザーベースのログアウトです。アプリケーションは、Red Hat Single Sign-On から定期的にセッションステータス情報を取得します。Red Hat Single Sign-On でセッションが終了すると、アプリケーションは通知し、独自のログアウトをトリガーします。

10.1.2.2. RP-Initiated Logout

これはブラウザーベースのログアウトでもあり、Red Hat Single Sign-On でユーザーを特定のエンドポイントにリダイレクトすることでログアウトが開始されます。このリダイレクトは通常、ユーザーが Red Hat Single Sign-On を使用してユーザーを認証していた一部のアプリケーションのページの Log Out リンクをクリックすると発生します。

ユーザーがログアウトエンドポイントにリダイレクトされると、Red Hat Single Sign-On はクライアントにログアウトリクエストを送信して、ローカルユーザーセッションを無効にし、ログアウトプロセスが終了したらユーザーを何らかの URL にリダイレクトできるようにします。id_token_hint パラメーターが使用されなかった場合、または id_token_hint からの ID トークンで参照されたクライアントで Consent Required が必要な場合に、ユーザーはオプションでログアウトの確認を求められることがあります。

クライアントの設定に応じて、ログアウト要求はフロントチャネルまたはバックチャネルを介してクライアントに送信できます。前のセクションで説明したセッション管理に依存するフロントエンドブラウザークライアントの場合、Red Hat Single Sign-On はログアウト要求をクライアントに送信する必要はありません。これらのクライアントは、ブラウザーの SSO セッションがログアウトしていることを自動的に検出します。

10.1.2.3. フロントチャンネルログアウト

フロントチャネルを介してログアウト要求を受信するようにクライアントを設定するには、フロントチャネルログアウトクライアントの設定を確認してください。この方法を使用するときは、次のことを考慮してください。

  • Red Hat Single Sign-On によってクライアントに送信されるログアウト要求は、ブラウザーと、ログアウトページ用にレンダリングされる組み込み iframe に依存します。
  • iframe に基づいているため、フロントチャネルのログアウトはコンテンツセキュリティーポリシー (CSP) の影響を受け、ログアウト要求がブロックされる可能性があります。
  • ログアウトページを表示する前、またはログアウト要求が実際にクライアントに送信される前にユーザーがブラウザーを閉じた場合、クライアントでのセッションが無効にならない可能性があります。
注記

Back-Channel Logout の使用を検討してください。これは、ユーザーがログアウトしてクライアントでセッションを終了するための、信頼性が高く安全な方法を提供します。

クライアントがフロントチャネルログアウトを有効にしていない場合、Red Hat Single Sign-On は最初に、バックチャネルログアウト URL を使用してバックチャネルを介してログアウト要求を送信しようとします。定義されていない場合は、サーバーは 管理 URL を使用するようにフォールバックします。

10.1.2.4. バックチャネルログアウト

これは、Red Hat Single Sign-On とクライアント間の直接バックチャンネル通信を使用する非ブラウザーベースのログアウトです。Red Hat Single Sign-On は、ログアウトトークンが含まれる HTTP POST リクエストを、Red Hat Single Sign-On にログインしたすべてのクライアントに送信します。これらのリクエストは、Red Hat Single Sign-On で登録されたバックチャンネルログアウト URL に送信され、クライアント側でのログアウトをトリガーする想定です。

10.1.3. Red Hat Single Sign-On サーバー OIDC URI エンドポイント

以下は、Red Hat Single Sign-On がパブリッシュする OIDC エンドポイントの一覧です。Red Hat Single Sign-On 以外のクライアントアダプターが OIDC を使用して認証サーバーと通信する場合に、これらのエンドポイントを使用できます。これらはすべて相対 URL です。URL のルートは、HTTP (S) プロトコル、ホスト名、およびオプションでパスで設定されます。たとえば、

https://localhost:8080/auth
/realms/{realm-name}/protocol/openid-connect/auth
Authorization Code Flow で一時的なコードを取得する場合、またはImplicit Flow、Direct Grants、または Client Grants を使用してトークンを取得する際に使用されます。
/realms/{realm-name}/protocol/openid-connect/token
一時コードをトークンに変換するために認可コードフローによって使用されます。
/realms/{realm-name}/protocol/openid-connect/logout
ログアウトの実行に使用されます。
/realms/{realm-name}/protocol/openid-connect/userinfo
OIDC 仕様で説明されている User Info サービスに使用されます。
/realms/{realm-name}/protocol/openid-connect/revoke
RFC7009 で説明されているように OAuth 2.0 Token Revocation に使用されます。
/realms/{realm-name}/protocol/openid-connect/certs
JSON Web Token (jwks_uri)の検証に使用される公開鍵が含まれる JSON Web Key Set (JWKS)に使用されます。
/realms/{realm-name}/protocol/openid-connect/auth/device
デバイスコードおよびユーザーコードを取得するために Device Authorization Grant に使用されます。
/realms/{realm-name}/protocol/openid-connect/ext/ciba/auth
これは、クライアントによって行われた認証要求を識別する auth_req_id を取得するためのクライアント主導のバックチャネル認証許可の URL エンドポイントです。
/realms/{realm-name}/protocol/openid-connect/logout/backchannel-logout
これは、OIDC 仕様で説明されているバックチャネルログアウトを実行するための URL エンドポイントです。

これらすべてで、{realm-name} をレルムの名前に置き換えます。

10.2. SAML

SAML 2.0 は OIDC と類似の仕様ですが、より成熟したものです。これは、SOAP および Web サービスメッセージングの仕様から派生するため、通常は OIDC よりも詳細になります。SAML 2.0 は、認証サーバーとアプリケーション間の XML ドキュメントを変換する認証プロトコルです。XML 署名と暗号化は、要求と応答の検証に使用されます。

通常、SAML は 2 つのユースケースを実装します。

最初のケースは、Red Hat Single Sign-On サーバーがユーザーを認証するように要求するアプリケーションです。ログインに成功すると、アプリケーションは XML ドキュメントを受け取ります。本書には、ユーザー属性を指定する SAML アサーションが含まれています。レルムは、アクセス情報(ユーザーロールマッピングなど)が含まれるドキュメントにデジタル署名します。アプリケーションは、この情報を使用してユーザーがアプリケーションでアクセスできるリソースを判断します。

2 つ目のユースケースは、リモートサービスにアクセスするクライアントです。クライアントは Red Hat Single Sign-On から SAML アサーションを要求し、ユーザーの代わりにリモートサービスを呼び出します。

10.2.1. SAML バインディング

Red Hat Single Sign-On は、3 つのバインディングタイプをサポートします。

10.2.1.1. リダイレクトバインディング

リダイレクト バインディングは一連のブラウザーリダイレクト URI を使用して情報を交換します。

  1. ユーザーは、ブラウザーを使用してアプリケーションに接続します。アプリケーションは、ユーザーが認証されていないことを検出します。
  2. アプリケーションは XML 認証リクエストドキュメントを生成し、これを URI のクエリーパラメーターとしてエンコードします。URI は Red Hat Single Sign-On サーバーにリダイレクトするために使用されます。設定によっては、アプリケーションは XML ドキュメントにデジタル署名し、署名を Red Hat Single Sign-On へのリダイレクト URI のクエリーパラメーターとして追加することもできます。この署名は、リクエストを送信するクライアントを検証するために使用されます。
  3. ブラウザーは Red Hat Single Sign-On にリダイレクトします。
  4. サーバーは XML 認証リクエストドキュメントを抽出し、必要に応じてデジタル署名を検証します。
  5. ユーザーは認証情報を入力します。
  6. 認証後、サーバーは XML 認証応答ドキュメントを生成します。ドキュメントには、名前、アドレス、電子メール、およびユーザーが持つロールマッピングなどのユーザーに関するメタデータを保持する SAML アサーションが含まれます。ドキュメントは通常、XML 署名を使用してデジタル署名され、暗号化もされる場合があります。
  7. XML 認証応答ドキュメントは、リダイレクト URI のクエリーパラメーターとしてエンコードされます。URI により、ブラウザーがアプリケーションに返されます。デジタル署名も、クエリーパラメーターとして含まれます。
  8. アプリケーションはリダイレクト URI を受け取り、XML ドキュメントを抽出します。
  9. アプリケーションはレルムの署名を検証し、有効な認証応答を受信していることを確認します。SAML アサーション内の情報は、アクセスの決定やユーザーデータの表示に使用されます。

10.2.1.2. POST バインディング

POST バインディングは リダイレクト バインディングと似ていますが、POST バインディングは GET リクエストの代わりに POST リクエストを使用して XML ドキュメントを交換します。POST バインディングは JavaScript を使用してブラウザーを漏洩し、ドキュメント交換時に Red Hat Single Sign-On サーバーまたはアプリケーションへの POST 要求を送信します。HTTP は、埋め込み JavaScript などの HTML フォームが含まれる HTML ドキュメントで応答します。ページを読み込むと、JavaScript はフォームを自動的に呼び出します。

POST バインディングは 2 つの制限があるために推奨されます。

  • セキュリティー: Redirect バインディングでは、SAML 応答は URL の一部です。ログで応答をキャプチャーする可能性があるため、安全性は低くなります。
  • サイズ: HTTP ペイロードでドキュメントを送信すると、制限された URL よりも、大量のデータに、より多くのスコープが提供されます。

10.2.1.3. ECP

Enhanced Client or Proxy (ECP) は、SAML v.2.0 プロファイルを表します。これにより、Web ブラウザーのコンテキスト外にある SAML 属性を交換できます。多くの場合、REST または SOAP ベースのクライアントによって使用されます。

10.2.2. Red Hat Single Sign-On Server SAML URI エンドポイント

Red Hat Single Sign-On には、すべての SAML 要求にエンドポイントが 1 つあります。

http(s)://authserver.host/auth/realms/{realm-name}/protocol/saml

すべてのバインディングはこのエンドポイントを使用します。

10.3. OpenID Connect と SAML の比較

以下は、プロトコルの選択時に考慮する必要のある複数の要素の一覧です。

ほとんどの目的で、Red Hat Single Sign-On は OIDC を使用することを推奨します。

OIDC

  • OIDC は、特に Web と連携するように設計されています。
  • OIDC は、SAML よりもクライアント側に簡単に実装できるため、HTML5/JavaScript アプリケーションにも適しています。
  • OIDC トークンは JSON 形式で、Javascript を簡単に消費できます。
  • OIDC には、セキュリティー実装を容易にするための機能があります。たとえば、ユーザーのログイン状態を決定するために仕様が使用する iframe のヒントを参照してください。

SAML

  • SAML は、Web 上で機能するレイヤーとして設計されています。
  • SAML は OIDC よりも詳細に指定できます。
  • 成熟していると考えられているので、ユーザーは OIDC ではなく SAML を選択します。
  • ユーザーは、セキュアな OIDC で SAML を選択します。

10.4. Docker Registry v2 認証

注記

Docker 認証はデフォルトで無効になっています。docker 認証を有効にするには、プロファイル を参照してください。

Docker レジストリー V2 認証 は OIDC と同様に、Docker レジストリーに対してユーザーを認証します。このプロトコルの Red Hat Single Sign-On の実装により、Docker クライアントは Red Hat Single Sign-On 認証サーバーをレジストリーに対して認証できるようにします。このプロトコルは標準のトークンと署名メカニズムを使用しますが、実際の OIDC 実装とは異なります。要求と応答に非常に特殊な JSON 形式を使用し、リポジトリー名とパーミッションを OAuth スコープメカニズムにマッピングすることで、非常に特殊な JSON 形式を使用します。

10.4.1. Docker 認証フロー

認証フローについては、Docker API のドキュメント で説明されています。以下は、Red Hat Single Sign-On 認証サーバーの視点の概要です。

  • docker login を実行します。
  • Docker クライアントは Docker レジストリーからリソースを要求します。リソースが保護されていて、要求に認証トークンがない場合には、Docker レジストリーサーバーは、必要なパーミッションに関する情報と承認サーバーの場所を示す 401 HTTP メッセージを返します。
  • Docker クライアントは、Docker レジストリーから 401 HTTP メッセージに基づいて認証要求を作成します。クライアントは、Red Hat Single Sign-On 認証サーバーへの HTTP Basic 認証 要求の一部として、(docker login コマンドからの)ローカルにキャッシュされた認証情報を使用します。
  • Red Hat Single Sign-On 認証サーバーは、ユーザーの認証を試みます。また、OAuth スタイルの Bearer トークンが含まれる JSON ボディーを返します。
  • Docker クライアントは JSON 応答から Bearer トークンを受け取り、これを Authorization ヘッダーで使用し、保護されているリソースを要求します。
  • Docker レジストリーは、Red Hat Single Sign-On サーバーからトークンを使用して保護されたリソースに対する新しい要求を受信します。レジストリーはトークンを検証し、要求されたリソースへのアクセスを付与します(該当する場合)。
注記

Red Hat Single Sign-On は、Docker プロトコルで認証に成功した後に、ブラウザーの SSO セッションは作成されません。ブラウザーの SSO セッションは、トークンを更新したり、Red Hat Single Sign-On サーバーからトークンまたはセッションのステータスを取得したりできないため、Docker プロトコルは使用されません。詳細は「一時的なセッション」を参照してください。

10.4.2. Red Hat Single Sign-On Docker Registry v2 Authentication Server URI Endpoints

Red Hat Single Sign-On には、すべての Docker auth v2 要求に対してエンドポイントは 1 つです。

http(s)://authserver.host/auth/realms/{realm-name}/protocol/docker-v2

第11章 管理コンソールへのアクセス制御

Red Hat Single Sign-On で作成された各レルムには、そのレルムを管理できる専用の管理コンソールがあります。master レルムは、管理者がシステムで複数のレルムを管理できるようにする特別なレルムです。異なるレルムでユーザーへの詳細なアクセスを定義して、サーバーを管理することもできます。本章では、このシナリオをすべて実施します。

11.1. マスターレルムアクセス制御

Red Hat Single Sign-On の master レルムは特別なレルムで、他のレルムとは異なる処理を行います。Red Hat Single Sign-On master レルムのユーザーは、Red Hat Single Sign-On サーバーにデプロイされるゼロ以上のレルムを管理するパーミッションを付与できます。レルムが作成されると、Red Hat Single Sign-On は、その新しいレルムにアクセスするための詳細な権限を付与するさまざまなロールを自動的に作成します。管理コンソールおよび管理 REST エンドポイントへのアクセスは、これらのロールを master レルムのユーザーにマッピングすることで制御できます。特定のレルムのみを管理できるユーザーは、複数のスーパーユーザーを作成することができます。

11.1.1. グローバルロール

master レルムには、2 つのレルムレベルのロールがあります。以下のとおりです。

  • admin
  • create-realm

admin ロールを持つユーザーはスーパーユーザーであり、サーバー上のレルムを管理するためにフルアクセスできます。create-realm ロールを持つユーザーは、新しいレルムを作成できます。このユーザーは、作成する新しいレルムに完全アクセスできます。

11.1.2. レルム固有のロール

master レルム内の管理者ユーザーには、システムの他のレルムに対して管理権限を付与できます。Red Hat Single Sign-On の各レルムは、master レルムのクライアントで表されます。クライアントの名前は <realm name>-realm です。これらのクライアントには、クライアントレベルのロールが定義されており、個別のレルムを管理するアクセスレベルを定義します。

利用可能なロールは以下のとおりです。

  • view-realm
  • view-users
  • view-clients
  • view-events
  • manage-realm
  • manage-users
  • create-client
  • manage-clients
  • manage-events
  • view-identity-providers
  • manage-identity-providers
  • impersonation

ユーザーに必要なロールを割り当てると、管理コンソールのその特定の部分のみを使用できます。

重要

manage-users ロールを持つユーザー管理者は、admin ロールを所有したユーザーにのみ割り当てることができます。したがって、admin に manage-users ロールがあり、manage-realm ロールがない場合、このロールを割り当てることができます。

11.2. 専用レルム管理コンソール

各レルムには、URL /auth/admin/{realm-name}/console に移動してアクセス可能な専用の管理コンソールがあります。特定のユーザーロールマッピングを割り当てることで、そのレルム内のユーザーにレルム管理パーミッションを付与できます。

各レルムには、realm-management と呼ばれる組み込みクライアントがあります。このクライアントは、レルムの左側のメニュー項目 Clients に移動すると表示できます。このクライアントは、レルムの管理に付与できるパーミッションを指定するクライアントレベルのロールを定義します。

  • view-realm
  • view-users
  • view-clients
  • view-events
  • manage-realm
  • manage-users
  • create-client
  • manage-clients
  • manage-events
  • view-identity-providers
  • manage-identity-providers
  • impersonation

ユーザーに必要なロールを割り当てると、管理コンソールのその特定の部分のみを使用できます。

11.3. 詳細にわたる管理者権限

注記

Fine Grain Admin Permissions はテクノロジープレビュー機能ですが、完全にサポートされていません。この機能はデフォルトでは無効にされます。

-Dkeycloak.profile=preview または -Dkeycloak.profile.feature.admin_fine_grained_authz=enabled を使用してサーバーを起動します。詳細は、Profiles を参照してください。

manage-realmmanage-users などのロールは粒度が荒すぎて、より詳細なパーミッションを持つ制限された admin アカウントの作成が必要になることがあります。Red Hat Single Sign-On を使用すると、レルム管理に制限付きアクセスポリシーを定義して割り当てることができます。以下に例を示します。

  • 特定のクライアントの管理
  • 特定グループに所属するユーザーの管理
  • グループのメンバーシップの管理
  • 制限されたユーザー管理。
  • 粒度の細かい偽装制御
  • ユーザーの特定の制限付きロールセットを割り当てることができる。
  • 特定の制限付きロールセットを複合ロールに割り当てることができます。
  • 特定の制限付きロールのセットをクライアントのスコープに割り当てることができます。
  • ユーザー、グループ、ロール、およびクライアントを表示および管理するための新しい一般的なポリシー。

詳細にわたる管理者権限で注目すべき重要な点があります。

  • 粒度の細かい管理権限は、承認サービス に実装されました。細分のパーミッションに分割する前に、この機能に対して読むことを強く推奨します。
  • 細かいアクセス権限は、専用の管理コンソールおよびそれらのレルム内でのみ利用できます。レルム間の細かいグラザブルパーミッションを定義することはできません。
  • 追加のパーミッションを付与するのに細かいパーミッションを使用します。ビルトインの admin ロールのデフォルト動作を上書きすることはできません。

11.3.1. 特定のクライアントの管理

最初に、管理者がクライアントを 1 つ、クライアントを 1 つだけ管理できるようにします。この例では、test という名前のレルムと、sales-application というクライアントがあります。レルム test では、そのレルムのパーミッションで、そのアプリケーションを管理する権限をユーザーに付与します。

重要

レルムの細かいアクセス権限をまたがって実行できません。master レルムの管理者は、以前の章で定義された事前定義済みの admin ロールに制限されます。

11.3.1.1. パーミッションのセットアップ

最初に管理コンソールにログインし、そのクライアントのパーミッションを設定できます。きめ細かなパーミッションを定義するクライアントの管理セクションに移動します。

クライアント管理

fine grain client

Permissions というタブメニュー項目が表示されるはずです。そのタブをクリックします。

クライアントパーミッションタブ

fine grain client permissions tab off

デフォルトでは、各クライアントは細かいパーミッションを実行することはできません。したがって、Permissions Enabled をオンにしてパーミッションを初期化します。

重要

Permissions Enabled スイッチをオフに設定すると、このクライアントに定義したすべてのパーミッションが削除されます。

クライアントパーミッションタブ

fine grain client permissions tab on

Permissions Enabled を on に切り替えると、承認サービスを使用して、背後でさまざまなパーミッションオブジェクトを初期化します。この例では、クライアントの 管理 パーミッションが対象になります。クライアントの manage パーミッションを処理するパーミッションにリダイレクトするものをクリックします。すべての承認オブジェクトは、realm-management クライアントの Authorization タブに含まれます。

クライアントパーミッションの管理

fine grain client manage permissions

最初に初期化された場合、manage パーミッションには関連付けられたポリシーがありません。policy タブに移動して作成する必要があります。高速に進むには、上記のイメージに表示される Authorization リンクをクリックします。次に、policies タブをクリックします。

このページに、Create policy というプルダウンメニューがあります。設定可能なさまざまなポリシーがあります。ロールまたはグループに関連付けられたポリシーを定義したり、JavaScript でルールを定義したりできます。この簡単な例では、User Policy を作成します。

ユーザーポリシー

fine grain client user policy

このポリシーは、ユーザーデータベースのハードコーディングされたユーザーと一致します。この場合、これは sales-admin ユーザーです。次に、sales-application クライアントの manage パーミッションページに戻り、ポリシーをパーミッションオブジェクトに割り当てる必要があります。

ユーザーグループの割り当て

fine grain client assign user policy

sales-admin ユーザーには、sales-application クライアントを管理するパーミッションが使用できるようになりました。

さらに 1 つのことが必要です。Role Mappings タブに移動し、query-clients ロールを sales-admin に割り当てます。

query-clients の割り当て

fine grain assign query clients

これを行う必要があるのはなぜですか?このロールは、sales-admin が管理コンソールにアクセスする際にレンダリングするメニュー項目を管理コンソールに指示します。query-clients ロールは、sales-admin ユーザーのクライアントメニューをレンダリングするよう管理コンソールに指示します。

IMPORTANT query-clients ロールを設定しない場合、sales-admin などの制限された管理者が管理コンソールにログインするときにメニューオプションは表示されません。

11.3.1.2. テスト

次に、master レルムからログアウトし、sales-admin をユーザー名として使用し、test レルムの 専用の管理コンソール に再ログインします。これは /auth/admin/test/console にあります。

営業管理者ログイン

fine grain sales admin login

これで、この admin がこのクライアントを 1 つ管理できるようになりました。

11.3.2. ユーザーロールのマッピングの制限

もう 1 つは、管理者がユーザーに割り当て可能なロールセットを制限することです。最後のサンプルを続行して、'sales-admin' ユーザーのパーミッションセットを拡張して、このアプリケーションにアクセスできるユーザーも制御できるようにします。きめ細かいパーミッションを使用することで、sales-adminsales-application への特定のアクセス権限を付与するロールのみを割り当てることができます。また、管理者はロールのみをマッピングでき、他のタイプのユーザー管理を実行しないように制限することもできます。

sales-application が 3 つの異なるクライアントロールを定義しました。

セールスアプリケーションロール

fine grain sales application roles

sales-admin ユーザーがこれらのロールをシステムの任意のユーザーにマッピングできるようにします。これを実行する最初のステップでは、ロールが admin でマップされるようにします。viewLeads ロールをクリックすると、このロールの Permissions タブがあることを確認できます。

Leads ロールのパーミッションタブの表示

fine grain view leads role tab

そのタブをクリックし、Permissions Enabled を on にすると、ポリシーを適用することのできる多数のアクションが表示されます。

Leads パーミッションの表示

fine grain view leads permissions

関心のあるのは map-role です。このパーミッションをクリックし、上記の例で作成されたのと同じ User Policy を追加します。

map-roles パーミッション

fine grain map roles permission

行った内容は、sales-adminviewLeads ロールをマッピングできることを示しています。何も指定していないユーザーは、管理者がこのロールをマップできるユーザーで指定します。このレルムの管理コンソールの Users セクションに移動する必要があります。左側のメニュー項目 Users をクリックすると、レルムのユーザーインターフェースが表示されます。Permissions タブが表示されるはずです。それをクリックして有効にします。

ユーザーパーミッション

fine grain users permissions

対象のパーミッションは map-roles です。これは、管理者のみがロールをユーザーにマッピングできるようにする制限ポリシーです。map-roles パーミッションをクリックし、作成したユーザーポリシーを再度追加すると、sales-admin はロールをどのユーザーにもマッピングできます。

最後に、view-users ロールを sales-admin に追加します。これにより、管理者は、sales-application ロールを追加するレルム内のユーザーを表示できます。

view-users の追加

fine grain add view users

11.3.2.1. テスト

次に、master レルムからログアウトし、sales-admin をユーザー名として使用し、test レルムの 専用の管理コンソール に再ログインします。これは /auth/admin/test/console にあります。

これで、sess-admin がシステムにユーザーを表示できるようになります。ユーザーの 1 つを選択すると、各ユーザー詳細ページが読み取り専用であることが表示されます (Role Mappings タブを除く)。これらのタブに移動すると、sales-application ロールを参照する場合を除き、管理者がユーザーにマップするのに Available となっているロールがないことが確認できます。

viewLeads の追加

fine grain add view leads

sales-adminviewLeads ロールをマッピングすることのみを指定しました。

11.3.2.2. クライアントごとの map-roles ショートカット

sales-application を公開するすべてのクライアントロールに対してこれを行う必要がある場合や、より容易になってしまうと、管理者がクライアントで定義されているすべてのロールをマップできるように指定する方法があります。マスターレルム admin に管理コンソールにログインし、sales-application パーミッションページに戻ると、map-roles パーミッションが表示されます。

クライアント map-roles パーミッション

fine grain client permissions tab on

この特別なパーミッションへのアクセスを管理者に付与すると、この管理者はクライアントで定義されるロールをマップできます。

11.3.3. パーミッションの完全リスト

特定のクライアントやクライアントの特定のロールの管理以外に、より詳細なパーミッションを設定することが可能です。本章では、レルムに設定できるパーミッションタイプ全体を定義します。

11.3.3.1. ロール

特定のロールの Permissions タブに移動すると、これらのパーミッションタイプが表示されます。

map-role
管理者がこのロールをユーザーにマッピングできるかどうかを決定するポリシー。これらのポリシーは、管理者がユーザーロールマッピングタスクを実行することが許可されているわけではなく、ロールをユーザーにマッピングできることのみを指定します。また、管理者は管理またはロールのマッピングパーミッションを持っている必要があります。詳細は、「ユーザーパーミッション」を参照してください。
map-role-composite
管理者がこのロールを複合としてマッピングできるかどうかを決定するポリシー。管理者は、そのクライアントのパーミッションを管理する必要があるにも拘らず、ロールの map-role-composite 権限がない場合は、クライアントのロールを定義できます。
map-role-client-scope
管理者がこのロールをクライアントの範囲に適用するかどうかを決定するポリシー。管理者がクライアントを管理できる場合でも、この特権が付与されない限り、このロールを含むクライアントのトークンを作成するパーミッションがありません。

11.3.3.2. クライアント

特定のクライアントのパーミッションタブに移動すると、これらのパーミッションタイプが表示されます。

view
管理者がクライアントの設定を表示できるかどうかを決定するポリシー。
manage
管理者がクライアントの設定を表示および管理するかどうかを判断するポリシー。この場合、意図せずに、特権がリークする可能性があるという問題があります。たとえば、管理者がロールをクライアントのスコープにマップする権限を持たない場合でも、管理者はロールをハードコーディングするプロトコルマッパーを定義できます。これは、現状に個別のパーミッションを割り当てる方法がないため、プロトコルマッパーの制限になります。
configure
クライアント管理の特権が減ります。管理者によるプロトコルマッパーの定義、クライアントテンプレートの変更、クライアントのスコープ変更が許可されていないことを除けば、管理スコープに似ています。
map-roles
管理者がクライアントで定義したロールをユーザーにマップできるかどうかを決定するポリシー。これはショートカットであり、使いやすく、クライアントが定義した各ロールのポリシーを定義する必要はありません。
map-roles-composite
管理者がクライアントで定義したロールを別のロールに複合としてマッピングできるかどうかを決定するポリシー。これはショートカットであり、使いやすく、クライアントが定義した各ロールのポリシーを定義する必要はありません。
map-roles-client-scope
管理者がクライアントで定義した任意のロールを別のクライアントのスコープにマッピングできるかどうかを決定するポリシー。これはショートカットであり、使いやすく、クライアントが定義した各ロールのポリシーを定義する必要はありません。

11.3.3.3. ユーザー

全ユーザーの Permissions タブに移動すると、全ユーザーのパーミッションタイプが一覧表示されます。

view
管理者がレルム内のすべてのユーザーを表示できるかどうかを決定するポリシー。
manage
管理者がレルム内のすべてのユーザーが管理できるかどうかを決定するポリシー。この権限は、管理者にユーザーロールマッピングを実行する権限を付与しますが、管理者がマッピングできるロールを指定するものではありません。admin がマッピングできるように、各ロールに特権を定義する必要があります。
map-roles
これは、manage スコープによって付与される権限のサブセットです。この場合、管理者はロールのみをマップできます。admin は、他のユーザー管理操作を実行できません。また、admin の適用が許可されるロールは、クライアントロールに対応する場合はロールごとまたはロールのセットごとに指定する必要があります。
manage-group-membership
map-roles と同様に、グループメンバーシップに関連するものを除き、ユーザーが追加または削除できるグループです。これらのポリシーは、管理者がメンバーシップを管理できるグループではなく、グループメンバーシップを管理する admin パーミッションを付与します。各グループの manage-members パーミッションにポリシーを指定する必要があります。
切り替え
他のユーザーの権限を借用できるかを決定するポリシー。これらのポリシーは、管理者の属性およびロールマッピングに適用されます。
user-impersonated
権限を借用できるユーザーを決定するポリシー。これらのポリシーは、権限を借用するユーザーに適用されます。たとえば、管理者権限のあるユーザーを偽装するポリシーを定義する場合などです。

11.3.3.4. グループ

特定のグループの Permissions タブに移動すると、これらのパーミッションタイプが表示されます。

view
管理者がグループの情報を表示するかどうかを決定するポリシー。
manage
管理者がグループの設定を管理するかどうかを決定するポリシー。
view-members
管理者がグループのメンバーのユーザーの詳細を表示できるかどうかを決定するポリシー。
manage-members
管理者がこのグループに所属するユーザーを管理するかどうかを決定するポリシー。
manage-membership
管理者がグループのメンバーシップを変更できるかどうかを決定するポリシー。グループからメンバーを追加または削除します。

第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 が発行するアクセストークンに、必要な対象範囲がすべて含まれていることを確認します。オーディエンスは、次のセクション またはハードコーディングで説明されているように、クライアントロールを使用して追加できます。ハードコードされた対象範囲 を参照