Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

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

手順

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

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

  1. Auth Flow の + メニューをクリックします。
  2. Add sub-flow をクリックします。
  3. 1st Condition Flow を名前として入力します。
  4. Add をクリックします。
  5. 1st Condition Flow 認証タイプの Conditional をクリックし、その要件を条件に設定します。
  6. 1st Condition Flow の + メニューをクリックします。
  7. Add condition をクリックします。
  8. リストから Conditional - Level Of Authentication を選択します。
  9. Add をクリックします。
  10. Conditional - Level Of Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
  11. ⚙️ (歯車アイコン) をクリックします。
  12. Level 1 をエイリアスとして入力します。
  13. レベル認証 (LoA) に 1 と入力します。
  14. Max Age を 36000 に設定します。この値は秒単位であり、10 時間に相当します。これは、レルムで設定されているデフォルトの SSO Session Max タイムアウトです。その結果、ユーザーがこのレベルで認証すると、その後の SSO ログインでこのレベルを再利用できるようになり、ユーザーセッション (デフォルトでは 10 時間) の終了まで、ユーザーはこのレベルで認証する必要がなくなります。

  15. Save をクリックします。

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

    Authentication step up condition 1

  16. 1st Condition Flow の + メニューをクリックします。
  17. Add step をクリックします。
  18. リストから Username Password Form を選択します。
  19. Add をクリックします。

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

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

  15. Save をクリックします。

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

    Autehtnication step up condition 2

  16. 2nd Condition Flow の + メニューをクリックします。
  17. Add step をクリックします。
  18. リストから OTP Form を選択します。
  19. Add をクリックします。
  20. OTP Form 認証タイプの Required をクリックして、その要件を必須に設定します。

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

  1. 画面上部の Action メニューをクリックします。
  2. リストから Bind flow を選択します。
  3. ドロップダウンから Browser Flow を選択します。
  4. Save をクリックします。

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

Authentication step up flow

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

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

https://{DOMAIN}/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 build of Keycloak の JavaScript アダプターは、この JSON を簡単に構築し、ログイン要求で送信できるようにサポートします。詳細は、アプリケーションの保護 セクションの Keycloak 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) を実行する必要があります。ただし、ユーザーがすでに Red Hat build of Keycloak でセッションを持っていて、ユーザー名とパスワード (LoA 1) を使用してログインしている場合、ユーザーには 2 番目の認証要素 (OTP) のみが求められます。

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

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

警告

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

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

注記

ユーザーの最初の認証中は、ユーザーにはまだレベルがないため、Conditional - Level Of Authentication で設定された最初のサブフローが常に実行されます (要求されたレベルに関係なく)。したがって、第 1 レベルのサブフローには、ユーザー認証に必要な最小限のオーセンティケーターを含めることを推奨します。さらに、上記の例に示すように、Conditional - Level Of Authentication の値が異なるサブフローが、最も低い値から順に並べられていることを確認します。たとえば、レベル 2 のサブフローを設定し、レベル 1 の別のサブフローを追加した場合、最初の認証時には常にレベル 2 のサブフローが要求されますが、これは望ましい動作ではない可能性があります。

注記

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

注記

認証レベル条件によるステップアップ認証は、各レベルで前のレベルのすべての認証方法が必要となるユースケースを対象としています。たとえば、レベル X には、レベル X-1 に必要なすべての認証方法が常に含まれている必要があります。レベル 3 などの特定のレベルで、以前のレベルとは異なる認証方法が必要なユースケースでは、ACR を特定のフローにマッピングする方が適切な場合があります。詳細は、クライアントポリシーを使用した認証フローの選択 を参照してください。

シナリオ例

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

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

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る