8.3. 認証フロー
認証フローは、認証、画面、およびアクションのコンテナー、ログイン、登録、およびその他の Red Hat Single Sign-On ワークフローのコンテナーです。すべてのフロー、アクション、およびチェックを表示するには、各フローには以下が必要です。
手順
- メニューで Authentication をクリックします。
- Flows タブをクリックします。
8.3.1. 組み込みフロー
Red Hat Single Sign-On には複数の組み込みフローがあります。これらのフローは変更できませんが、フローの要件をニーズに合わせて変更することができます。
ドロップダウンリストで、ブラウザー を選択して Browser Flow 画面を表示します。
ブラウザーのフロー
ドロップダウンリストの question-mark ツールにカーソルを合わせ、フローの説明を表示します。2 つのセクションがあります。
8.3.1.1. 認証タイプ
実行する認証またはアクションの名前。認証がインデントされると、これはサブフローにあります。これは、親の動作によって実行されるか、実行されていない可能性があります。
cookie
ユーザーが初めてログインすると、Red Hat Single Sign-On はセッションクッキーを設定します。クッキーがすでに設定されている場合、この認証タイプは成功します。Cookie プロバイダーが成功し、各フローのレベルでの実行は 代替 であるため、Red Hat Single Sign-On は他の実行を実行しません。これにより、ログインに成功します。
Kerberos
このオーセンティケーターはデフォルトで無効になっており、ブラウザーフローではスキップされます。
アイデンティティープロバイダーのリダイレクター
このアクションは、Actions > Config リンクで設定されます。Identity Brokering のために別の IdP にリダイレクトします。
フォーム
このサブフローは 代替 としてマークされているため、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. Disabled
要素は、フローに successful というマークを付けることはできません。
8.3.1.2.4. 条件付き
この要件タイプはサブフローにのみ設定されます。
- Conditional サブフローには実行が含まれます。これらの実行は論理ステートメントに評価する必要があります。
- すべての実行が true として評価されると、Conditional サブフローは必須として動作します。
- すべての実行が false と評価されると、Conditional サブフローは Disabled として機能します。
- 実行を設定しない場合、Conditional サブフローは Disabled として機能します。
- フローに実行が含まれ、フローが Conditional に設定されていない場合、Red Hat Single Sign-On は実行を評価せず、実行は機能的に Disabled と見なされます。
8.3.2. フローの作成
フローの設計時に、重要な機能およびセキュリティー上の考慮事項が適用されます。
フローを作成するには、以下を実行します。
手順
- メニューで Authentication をクリックします。
- New をクリックします。
既存のフローをコピーおよび変更できます。フローを選択し、Copy をクリックし、新しいフローの名前を入力します。
新しいフローを作成する場合は、まず以下のオプションでトップレベルフローを作成する必要があります。
- Alias
- フローの名前。
- Description
- フローに設定できる説明。
- Top-Level Flow Type
- フローのタイプ。タイプ クライアントは、クライアント (アプリケーション) の認証にのみ使用されます。その他のケースについては、generic を選択します。
トップレベルフローの作成
Red Hat Single Sign-On がフローを作成すると、Red Hat Single Sign-On に Delete、Add execution、および Add flow ボタンが表示されます。
空の新規フロー
3 つの要因により、フローとサブフローの動作が決定されます。
- フローおよびサブフローの構造。
- フロー内での実行
- サブフローおよび実行内で設定される要件。
リセットメールの送信から OTP の検証まで、実行にはさまざまなアクションを設定できます。Add execution ボタンで実行を追加します。Provider の横にある疑問符にカーソルを合わせ、実行の説明を確認します。
認証実行の追加
自動実行とインタラクティブな実行の 2 種類の実行があります。自動実行 は Cookie 実行に類似し、フローのアクションを自動的に実行します。インタラクティブな実行は、入力を取得するためにフローを停止します。正常に実行されると、ステータスを success に設定します。フローが完了するには、ステータスが success の実行が少なくとも 1 つ必要です。
Add flow ボタンを使用して、サブフローを最上位のフローに追加できます。Add flow ボタンをクリックすると、Create Execution Flow ページが表示されます。このページは Create Top Level Form ページに似ています。相違点は、Flow Type を generic(デフォルト) または form に設定できることです。form タイプは、組み込み Registration フローに似た、ユーザーのフォームを生成するサブフローを構築します。サブフローが成功するかどうかは、含まれるサブフローを含め、実行がどのように評価されるかによります。サブフローがどのように機能するかの詳細な説明については、実行要件 セクションを参照してください。
実行を追加したら、要件の値が正しいことを確認します。
フローのすべての要素には、Actions メニューに Delete オプションがあります。このアクションは、フローから要素を削除します。実行には、実行を設定するための Config メニューオプションがあります。Add execution および Add flow メニューオプションで、実行およびサブフローをサブフローに追加することもできます。
実行の順序は重要であるため、名前の横にある上下ボタンで、実行とサブフローをフロー内で上下に動かすことができます。
認証フローを設定するときは、設定を適切にテストして、セットアップにセキュリティーホールが存在しないことを確認してください。さまざまなコーナーケースをテストすることが推奨されます。たとえば、認証前にユーザーのアカウントからさまざまな認証情報を削除するときに、ユーザーの認証動作をテストすることを検討してください。
たとえば、OTP フォームや WebAuthn オーセンティケーターなどの第 2 要素オーセンティケーターがフローで REQUIRED として設定されていて、ユーザーが特定のタイプのクレデンシャルを持っていない場合、ユーザーは認証自体の間に特定のクレデンシャルをセットアップできます。この状況は、認証中にユーザーがこの認証情報で認証されないことを意味します。ブラウザー認証の場合は、Password や WebAuthn Passwordless Authenticator などの一部の 1 つの要素認証情報で認証フローを設定してください。
8.3.3. パスワードなしのブラウザーログインフローの作成
フローの作成を説明するために、本セクションでは高度なブラウザーログインフローの作成について説明します。このフローの目的は、ユーザーが、WebAuthn によるパスワードなしの方法でのログインと、パスワードと OTP を使用した二要素認証を選択できるようにすることです。
手順
- メニューで Authentication をクリックします。
- Flows タブをクリックします。
- New をクリックします。
-
エイリアスとして
Browser Password-less
を入力します。 - Save をクリックします。
- Add execution をクリックします。
- ドロップダウンリストから Cookie を選択します。
- Save をクリックします。
- Cookie 認証タイプの Alternative をクリックして、その要件を代替に設定します。
- Add execution をクリックします。
- ドロップダウンリストから Kerberos を選択します。
- Add execution をクリックします。
- ドロップダウンリストから Identity Provider Redirector を選択します。
- Save をクリックします。
- Identity Provider Redirector 認証タイプの Alternative をクリックして、その要件を代替に設定します。
- Add flow をクリックします。
- エイリアスとして Forms を入力します。
- Save をクリックします。
Forms 認証タイプの Alternative をクリックして、その要件を代替に設定します。
ブラウザーフローの共通部分
- Forms 実行の Actions をクリックします。
- Add execution を選択します。
- ドロップダウンリストから Username Form を選択します。
- Save をクリックします。
- Username Form 認証タイプの Required をクリックして、その要件を必須に設定します。
この段階では、フォームにはユーザー名が必要ですが、パスワードは必要ありません。セキュリティーリスクを回避するために、パスワード認証を有効にする必要があります。
- Forms サブフローの Actions をクリックします。
- Add flow をクリックします。
-
エイリアスとして
Authentication
を入力します。 - Save をクリックします。
- Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
- Authentication サブフローの Actions をクリックします。
- Add execution をクリックします。
- ドロップダウンリストから Webauthn Passwordless Authenticator を選択します。
- Save をクリックします。
- Webauthn Passwordless Authenticator 認証タイプの Alternative をクリックして、その要件を代替に設定します。
- Authentication サブフローの Actions をクリックします。
- Add flow をクリックします。
-
エイリアスとして
Password with OTP
を入力します。 - Save をクリックします。
- Password with OTP 認証タイプの Alternative をクリックして、その要件を代替に設定します。
- Password with OTP サブフローの Actions をクリックします。
- Add execution をクリックします。
- ドロップダウンリストから Password Form を選択します。
- Save をクリックします。
- Password Form 認証タイプの Required をクリックして、その要件を必須に設定します。
- Password with OTP サブフローの Actions をクリックします。
- Add execution をクリックします。
- ドロップダウンリストから OTP Form を選択します。
- Save をクリックします。
- OTP Form 認証タイプの Required をクリックして、その要件を必須に設定します。
最後に、バインディングを変更します。
- Bindings タブをクリックします。
- Browser Flow ドロップダウンリストをクリックします。
- ドロップダウンリストから Browser Password-less を選択します。
- Save をクリックします。
パスワードなしのブラウザーログイン
ユーザー名を入力すると、フローは以下のように機能します。
ユーザーの WebAuthn パスワードレス認証情報が記録されている場合は、これらの認証情報を使用して直接ログインできます。これはパスワードなしのログインです。WebAuthn Passwordless
実行および Password with OTP
フローが Alternative に設定されているため、ユーザーは Password with OTP を選択することもできます。Required に設定されている場合は、ユーザーは WebAuthn、パスワード、および OTP を入力する必要があります。
ユーザーが WebAuthn passwordless
認証で Try another wayのリンクを選択する場合、ユーザーは Password
と Security Key
(WebAuthn パスワードレス) のいずれかを選択できます。パスワードを選択すると、ユーザーは続行して、割り当てられた OTP でログインする必要があります。ユーザーに WebAuthn 認証情報がない場合は、ユーザーはパスワードを入力し、続いて OTP を入力する必要があります。ユーザーに OTP 認証情報がない場合は、記録することが要求されます。
WebAuthn Passwordless 実行は Required ではなく Alternative に設定されているため、このフローはユーザーに WebAuthn 認証情報を登録するように要求しません。ユーザーに Webauthn 認証情報を設定するには、管理者がユーザーに必須アクションを追加する必要があります。これを行うには、以下を実行します。
- レルムで Webauthn Register Passwordless で必須アクションを有効にします (WebAuthn のドキュメントを参照)。
- ユーザーの 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. ステップアップメカニズムを使用したブラウザーログインフローの作成
本セクションでは、ステップアップメカニズムを使用して高度なブラウザーログインフローを作成する方法を説明します。ステップ認証の目的は、ユーザーの特定の認証レベルに基づいてクライアントまたはリソースへのアクセスを許可することです。
手順
- メニューで Authentication をクリックします。
- Flows タブをクリックします。
- New をクリックします。
-
Browser Incl Step up Mechanism
をエイリアスとして入力します。 - Save をクリックします。
- Add execution をクリックします。
- アイテムリストから Cookieを選択します。
- Save をクリックします。
- Cookie 認証タイプの Alternative をクリックして、その要件を代替に設定します。
- Add flow をクリックします。
- Auth Flow をエイリアスとして入力します。
- Save をクリックします。
- Auth Flow 認証タイプの Alternative をクリックして、その要件を代替に設定します。
最初の認証レベルのフローを設定します。
- Auth Flow の Actions をクリックします。
- Add flow をクリックします。
-
1st Condition Flow
をエイリアスとして入力します。 - Save をクリックします。
- 1st Condition Flow 認証タイプの Conditional をクリックし、その要件を条件に設定します。
- 1st Condition Flow の Actions をクリックします。
- Add execution をクリックします。
- 項目 リストから Conditional - Level Of Authentication を選択します。
- Save をクリックします。
- Conditional - Level Of Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
- Conditional - Level Of Authentication の Actions をクリックします。
- Config をクリックします。
-
Level 1
をエイリアスとして入力します。 -
レベル認証 (LoA) に
1
と入力します。 -
Max Age を 36000 に設定します。この値は秒単位であり、10 時間に相当します。これは、レルムで設定されているデフォルトの
SSO Session Max
タイムアウトです。その結果、ユーザーがこのレベルで認証される場合、後続の SSO ログインはこのレベルを再利用でき、ユーザーセッションが終了するまでユーザーはこのレベルで認証する必要はありません (デフォルトでは 10 時間)。 Save をクリックします。
最初の認証レベルの条件を設定します。
- 1st Condition Flow の Actions をクリックします。
- Add execution をクリックします。
- アイテムリストから Usernmae Password Form を選択します。
- Save をクリックします。
- Username Password Form 認証タイプの Required をクリックして、その要件を必須に設定します。
これで、2 つ目の認証レベルのフローが設定されます。
- Auth Flow の Actions をクリックします。
- Add flow をクリックします。
-
2nd Condition Flow
をエイリアスとして入力します。 - Save をクリックします。
- 2st Condition Flow 認証タイプの Conditional をクリックし、その要件を条件に設定します。
- 2st Condition Flow の Actions をクリックします。
- Add execution をクリックします。
- 項目 リストから Conditional - Level Of Authentication を選択します。
- Save をクリックします。
- Conditional - Level Of Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
- Conditional - Level Of Authentication の Actions をクリックします。
- Config をクリックします。
-
Level 2
をエイリアスとして入力します。 -
認証レベル (LoA) に
2
と入力します。 - Max Age を 0 に設定します。その結果、ユーザーが認証する場合、このレベルは現在の認証に対してのみ有効ですが、後続の SSO 認証に対しては有効ではありません。したがって、このレベルが要求された場合、ユーザーは常にこのレベルで再度認証する必要があります。
Save をクリックします。
2 つ目の認証レベルの条件を設定する
- 2st Condition Flow の Actions をクリックします。
- Add execution をクリックします。
- アイテムリストから OTP Form を選択します。
- Save をクリックします。
- OTP Form 認証タイプの Required をクリックして、その要件を必須に設定します。
最後に、バインディングを変更します。
- Bindings タブをクリックします。
- Browser Flow item リストをクリックします。
- 項目リストから Browser Incl Step up Mechanism を選択します。
- Save をクリックします。
ステップアップメカニズムによるブラウザーログイン
特定の認証レベルを要求します。
ステップアップメカニズムを使用するには、認証リクエストに要求された認証レベル (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
パラメーター要求が存在しない場合に使用されます。詳細については、クライアント ACR 設定 を参照してください。
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 に送信されるときに、claim
や acr_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 が一貫していることを確認するのは管理者次第です。
シナリオ例
- Max Age は、レベル 1 の状態で 300 秒として設定されています。
-
ログイン要求は、acr を要求せずに送信されます。レベル 1 が使用され、ユーザーはユーザー名とパスワードで認証する必要があります。トークンには
acr=1
があります。 -
別のログイン要求は 100 秒後に送信されます。SSO によりユーザーが自動的に認証され、トークンは
acr=1
を返します。 -
さらに 201 秒 (ポイント 2 での認証から 301 秒) 後に別のログイン要求が送信されます。ユーザーは SSO により自動的に認証されますが、レベル 1 が期限切れと見なされるため、トークンは
acr=0
を返します。 -
別のログイン要求が送信されますが、これで、
claims
パラメーターでレベル 1 の ACR が明示的に要求されます。ユーザーはユーザー名/パスワードで再認証するように求められ、その後acr=1
がトークンで返されます。
トークンの ACR クレーム
ACR 要求は、acr
クライアントスコープで定義された acr loa level
の プロトコルマッパーによってトークンに追加されます。このクライアントスコープはレルムのデフォルトのクライアントスコープであるため、レルム内に新しく作成されたすべてのクライアントに追加されます。
トークン内で acr
クレームが必要ない場合、またはトークンを追加するためのカスタムロジックが必要な場合は、クライアントからクライアントスコープを削除できます。
ログイン要求が acr
を essential
の要求として要求する claims
パラメーターを使用して要求を開始すると、Red Hat Single Sign-On は常に指定されたレベルの 1 つを返すことに注意してください。指定されたレベルの 1 つを返すことができない場合 (たとえば、要求されたレベルが不明であるか、認証フローで設定された条件よりも大きい場合)、Red Hat Single Sign-On はエラーを出力します。
8.3.5. ユーザーセッション制限の設定
ユーザーが持つことができるセッション数の制限を設定できます。セッションは、レルムごとまたはクライアントごとに制限できます。
フローにセッション制限を追加するには、次の手順を実行します。
- フローの 実行の追加 をクリックします。
- 項目 リストから User Session Count Limiter を選択します。
- Save をクリックします。
- ユーザーセッションカウントリミッター 認証タイプの 必須 をクリックして、要件を必須に設定します。
- ユーザーセッション数制限の アクション をクリックします。
- Config をクリックします。
- この設定のエイリアスを入力します。
- このレルムでユーザーが持つことができるセッションの最大数を入力します。0 の値を使用すると、このチェックは無効になります。
- クライアントにユーザーが持つことができるセッションの最大数を入力します。0 の値を使用すると、このチェックは無効になります。
制限に達するとユーザーがセッションを作成しようとすると必要な動作を選択します。利用可能な動作は以下のとおりです。
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.
- 必要に応じて、制限に達すると表示されるカスタムエラーメッセージを追加します。
ユーザーセッションの制限は、バインドされた Browser Flow、Direct Grant Flow、Reset Credentials、および設定された ID プロバイダーのすべての Post Login Flow に追加する必要があることに注意してください。現在、管理者は異なる設定間で整合性を維持します。
また、CIBA ではユーザーセッション制限機能は利用できないことに注意してください。