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

8.10. 条件付きフローの条件

実行要件 で述べたように、条件 実行は 条件付き サブフローにのみ含めることができます。すべての 条件 実行が true と評価されると、Conditional サブフローは Required として機能します。Conditional サブフローの次の実行を処理できます。Conditional サブフローに含まれる一部の実行が false と評価されると、サブフロー全体が Disabled と見なされます。

8.10.1. 利用可能な条件
リンクのコピー

Condition - User Role

この実行では、ユーザーに User role フィールドで定義されているロールがあるかどうかを判別できます。ユーザーに必要なロールが割り当てられている場合、実行は true と判断され、その他の実行が評価されます。管理者は以下のフィールドを定義する必要があります。

Alias
認証フローに表示される実行の名前を記述します。
User role
このフローを実行するために必要なユーザーロール。アプリケーションロールを指定する場合、構文は appname.approle(myapp.myrole など) です。
Condition - User Configured
これは、フローの他の実行がユーザーに設定されているかどうかを確認します。実行要件のセクションには、OTP フォームの例が含まれています。
Condition - User Attribute

ユーザーが必須の属性を設定したかチェックします。このチェックでは、オプションでグループ属性も評価できます。出力が否定される可能性があります。この場合、ユーザーに属性を設定することはできません。ユーザー属性 セクションに、カスタム属性を追加する方法が説明されています。以下のフィールドを指定できます。

Alias
認証フローに表示される実行の名前を記述します。
Attribute name
確認する属性の名前。
Expected attribute value
属性の想定される値。
Include group attributes
この条件を On にすると、参加したグループのいずれかに、設定された名前と値に一致する属性が 1 つあるかチェックします。このオプションはパフォーマンスに影響を与える可能性があります。
Negate output
出力を否定することができます。つまり、この属性は存在しません。
条件 - sub-flow executed

この条件は、認証プロセスで前のサブフローが正常に実行されたかどうか (または実行されなかったかどうか) をチェックします。したがって、フローは以前のサブフローの終了に基づいて他のステップをトリガーできます。次の設定フィールドが存在します。

Flow name
実行されたかどうかを確認するサブフロー名。必須。
Check result
条件が true と評価された場合。設定したサブフローが実行され、Success と出力された場合に、executed は true を、それ以外は false を返します。サブフローが実行され、Success と出力された場合に、not-executed は false を、それ以外の場合は true (前のオプションの否定) を返します。
条件 - client scope

認証を要求するクライアントのクライアントスコープとして設定されたクライアントスコープが存在するかどうかを評価する条件。次の設定フィールドが存在します。

Client scope name
認証をリクエストするクライアントのクライアントスコープとして存在する必要があるクライアントスコープの名前。ログインをリクエストしているクライアントにとって、リクエストされたクライアントスコープがデフォルトスコープである場合、この条件は true として評価されます。リクエストされたクライアントスコープが、ログインをリクエストしているクライアントに設定された任意のクライアントスコープである場合、クライアントがログインリクエストの中でそのスコープを指定して送信している場合 (例: OIDC/OAuth2 の scope パラメータなど)、条件は true として評価されます。必須。
Negate output
チェック結果に NOT を適用します。これが true の場合、設定されたクライアントスコープが存在しない場合にのみ、条件は true と評価されます。
Condition - credential

この条件は、ユーザーが認証プロセス中に特定の認証情報タイプが使用されているか、または使用されていないかを評価します。設定オプション：

認証情報
条件によって考慮される認証情報のリスト。
同梱
contains が true の場合、credentials オプションで指定された認証情報のいずれかが認証プロセスで使用さ れる と、条件は true と評価されます。それ以外の場合は false になります。included が false の場合、条件は逆の方法で評価されます。設定された 認証情報 のいずれも使用されていない場合は true、いずれか 1 つ以上が使用されている場合は false になります。

8.10.2. 条件付きフローでのアクセスの明示的な拒否/許可
リンクのコピー

条件付きフローのリソースへのアクセスを許可または拒否できます。2 つのオーセンティケーターの Deny Access と Allow 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 実行が含まれます。

Browser Flow

Deny access flow

Condition - user role configuration

Deny access role settings

Deny Access の設定は非常に簡単です。以下のように、任意のエイリアスと必要なメッセージを指定できます。

Deny access execution settings

最後に、ログインテーマのエラーメッセージのプロパティー messages_en.properties(英語の場合) を定義します。 

deny-role1 = You do not have required role!
Copy to Clipboard Toggle word wrap

8.10.3. 2FA 条件付きワークフローの例
リンクのコピー

このセクションでは、さまざまな方法で二要素認証 (2FA) を統合する条件付きワークフローの例をいくつか紹介します。例では、デフォルトの browser フローをコピーし、forms サブフロー内の設定を変更します。

8.10.3.1. Conditional 2FA サブフロー
リンクのコピー

デフォルトの ブラウザー フローは、OTP フォーム（ワンタイムパスワード）を持つ 2 番目の係数認証(2FA)をすでに提供している Conditional 2FA サブフローを使用します。WebAuthn およびリカバリーコードも提供しますが、デフォルトでは無効になっています。このアプローチに一貫性があり、異なる 2FA メソッドを Condition - User Configured と統合することができます。

2FA all alternative

2FA all alternative

forms サブフローには Condition - user configured のある別の 2FA 条件付きサブフローが含まれています。代わりのステップとして、3 つの 2FA のステップ (OTP、Webauthn、リカバリーコード) が許可されます。ユーザー向けに設定されている場合は、3 つのオプションのいずれかを選択できます。サブフローは条件付きであるため、2FA 認証情報が設定されていない場合でも認証プロセスは正常に完了します。

この設定は、両方の 無効 ステップを使用してデフォルトの ブラウザー フローで設定する場合と同じ動作をし ます。

8.10.3.2. Conditional 2FA サブフローと Deny access
リンクのコピー

2 番目の例は前の例の続きです。2FA サブフローの後、別のフロー Deny access if no 2FA を使用して、前の 2FA が実行されなかったかどうかを確認します。その場合 (ユーザーに 2FA 認証情報が設定されていない場合)、アクセスは拒否されます。

2FA all alternative および Deny access

2FA all alternative and deny access

Condition - sub-flow executed は 2FA サブフローが以前に実行されていないかどうかを検出するように設定されています。

sub-flow executed の設定

Configuration for the sub-flow executed

Deny access のステップは、実行されない場合、認証を拒否します。

8.10.3.3. OTP がデフォルトの Conditional 2FA サブフロー
リンクのコピー

最後の例は前の例と非常に似ています。アクセスを拒否する代わりに、必要に応じて OTP Form のステップが設定されます。

OTP がデフォルトの 2FA all alternative

2FA all alternative with OTP default

このフローでは、ユーザーが 2FA 方式をいずれも設定していない場合は、OTP 設定を有効にし、ログインを続行します。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat