5.6. アプリケーション起点のアクション
アプリケーション起点のアクション (AIA) を使用すると、クライアントアプリケーションは、ユーザーに Red Hat build of Keycloak でアクションを実行するように要求できます。通常、OIDC クライアントアプリケーションは、ユーザーにログインを要求する場合、OIDC セクション で説明されているように、そのユーザーをログイン URL にリダイレクトします。ログイン後、ユーザーはクライアントアプリケーションにリダイレクトされます。ユーザーは、前のセクション で説明したように管理者によって要求されたアクションを実行し、すぐにアプリケーションにリダイレクトされます。しかし、AIA を使用すると、クライアントアプリケーションは、ログイン時にユーザーに対して特定の必須アクションを要求できます。これは、ユーザーがクライアント上ですでに認証されており、アクティブな SSO セッションがある場合でも実行できます。これは、要求されたアクションを含む値を持つ kc_action パラメーターを OIDC ログイン URL に追加することによってトリガーされます。たとえば、kc_action=UPDATE_PASSWORD パラメーターです。
ユーザーはアプリケーションによって開始されたアクションをキャンセルできます。この場合、ユーザーはクライアントアプリケーションにリダイレクトされます。リダイレクト URI には、キャンセルされたアクションの名前を含むクエリーパラメーター kc_action_status=cancelled と kc_action が含まれます。
kc_action および kc_action_status パラメーターは、OIDC 仕様でサポートされていない Red Hat build of Keycloak のプロプライエタリーメカニズムです。
アプリケーション起点のアクションは、OIDC クライアントに対してのみサポートされます。
したがって、AIA を使用する場合、フローの例は次のようになります。
-
クライアントアプリケーションは、
kc_action=UPDATE_PASSWORDなどの追加パラメーターを使用して、ユーザーを OIDC ログイン URL にリダイレクトします。 -
認証フローのセクション で説明されているように、常に
ブラウザーフローがトリガーされます。ユーザーが認証されなかった場合、そのユーザーは通常のログイン時と同様に認証する必要があります。ユーザーがすでに認証されている場合、そのユーザーは、アクティブに再認証して認証情報を再度入力する必要なく、SSO Cookie によって自動的に再認証される可能性があります。この場合、そのユーザーは特定のアクション (この場合はパスワードの更新) を実行する画面に直接リダイレクトされます。ただし、場合によっては、ユーザーが SSO Cookie を持っている場合でも、アクティブな再認証が必要になります (詳細は こちら を参照してください)。 -
特定のアクション (この場合は
update password) の画面がユーザーに表示されるため、ユーザーは特定のアクションを実行する必要があります。 - その後、ユーザーはクライアントアプリケーションにリダイレクトされます。
AIA は、Red Hat build of Keycloak アカウントコンソール でパスワードの更新を要求したり、OTP や WebAuthn などの他の認証情報をリセットしたりするために使用されることに注意してください。
パラメーター kc_action が使用されたとしても、ユーザーが常にアクションを実行すると想定するだけでは不十分です。たとえば、ユーザーがブラウザーの URL から kc_action パラメーターを手動で削除した可能性があります。したがって、クライアントが kc_action=CONFIGURE_TOTP を要求した後、ユーザーがアカウントの OTP を持っているという保証はありません。ユーザーが 2 要素認証を設定したことを検証する場合は、クライアントアプリケーションでそれが設定されていることを確認する必要があります。たとえば、トークン内の acr のようなクレームを確認します。
5.6.1. AIA 中の再認証 リンクのコピーリンクがクリップボードにコピーされました!
アクティブな SSO セッションによりユーザーがすでに認証されている場合、通常、そのユーザーはアクティブに再認証する必要はありません。ただし、そのユーザーが 5 分以上前にアクティブに認証されている場合、クライアントは AIA が要求されたときに再認証を要求できます。このガイドラインには次のような例外があります。
- Required actions タブ で、必須アクションごとに、必須アクション自体の最大有効期間を設定できます。ポリシーが設定されていない場合は、デフォルトで 5 分に設定されます。
-
delete_accountアクションでは、常にユーザーが能動的に再認証する必要があります。 -
UPDATE_PASSWORDアクションが、設定された 認証の最大有効期間のパスワードポリシー に従って、ユーザーが能動的に再認証するよう要求する可能性があります。ポリシーが設定されていない場合は、特定の必須アクションを設定するときに、Required actions tab で必須アクション自体にポリシーを設定することもできます。これらのいずれの場所でもポリシーが設定されていない場合は、デフォルトで 5 分に設定されます。 -
より短い再認証を使用する場合は、指定されたより短い値を持つ
max_ageなどのパラメータークエリーパラメーターを使用するか、最終的にはprompt=loginを使用できます。これにより、OIDC 仕様で説明されているように、ユーザーによる能動的な再認証が常に要求されます。デフォルトの 5 分 (または必須アクション用に特別に設定した値) よりも長い値のmax_ageを使用することはサポートされていないことに注意してください。現在、max_ageは、値をデフォルトの 5 分より短くするためにのみ使用できます。 -
ステップアップ認証が 有効になっていて、操作が認証情報の追加または削除である場合、指定された認証情報に対応するレベルの認証が必要になります。この要件は、ユーザーがすでに特定のレベルの認証情報を持っている場合に存在します。たとえば、認証フローで
otpとwebauthnが 2 番目の要素認証子として設定されていて (両方とも認証フローのレベル 2)、ユーザーがすでに 2 番目の要素認証情報 (この場合はotpまたはwebauthn) を持っていると、ユーザーは既存の 2 番目の要素認証情報を使用して認証し、別の 2 番目レベルの認証情報を追加する必要があります。同様に、既存の 2 番目の要素認証情報 (この場合はotpまたはwebauthn) を削除する場合は、既存の 2 番目の要素レベルの認証情報による認証が必要になります。この要件はセキュリティー上の理由から存在します。