6.3. 管理

ユーザーは、よりセキュアで一貫したフローで、メールアドレスを更新できるようになりました。アカウントは、更新する前にアカウントの再認証とメールの確認が強制されます。

詳細は、Update Email Workflow を参照してください。

以前のバージョンでは、各組織に少なくとも 1 つのメールドメインが必要であり、これが一部のシナリオでは制限となっていました。このリリース以降、メールドメインはオプションになります。

ドメインが指定されていない場合、認証およびプロファイル検証中に、組織のメンバーがドメイン制限に照らして検証されません。

Show in Account console 設定を使用して、さまざまなオプションに基づいて、Account Console に表示されるアイデンティティープロバイダーを制御できるようになりました。ユーザーにリンクされているものだけを表示するか、それらを完全に非表示にするかを選択できます。

詳細は、一般的な設定 を参照してください。

OTP とリカバリーコードを認証の第 2 要素として有効にしている場合、ユーザーが OTP をセットアップした後、リカバリーコードもセットアップするように求めるよう、OTP 必須アクションを設定できます。

条件付き認証情報 は、認証プロセス中に特定の認証情報タイプが使用されたか (または使用されていないか) を確認する新しいオーセンティケーターです。この状態は、パスキー機能に関連しています。これは、プライマリー認証情報としてパスキーを使用してログインした場合に 2FA をスキップするために、Red Hat build of Keycloak によってデフォルトのブラウザーフローに追加されました。

条件付きフローの詳細は、条件付きフローの条件 を参照してください。

ユーザーは、2FA 認証情報を紛失するとアカウントからロックアウトされる可能性があります。たとえば、ユーザーは認証の第 2 要素としてワンタイムパスワード (OTP) ジェネレーターを備えたスマートフォンを持っているとします。そのユーザーがスマートフォンを紛失すると、ロックアウトされてしまう可能性があります。

この問題を回避するため、ユーザーはリカバリーコード一式を追加の第 2 要素として印刷できます。リカバリーコードは、ログインフローにおける代替の 2FA になります。その結果、ユーザーは OTP で生成されたパスワードを使用せずにアクセスできます。

このリリースでは、リカバリーコード機能がプレビューからサポート対象機能に昇格されました。新しく作成されたレルムの場合、ブラウザーフローに Recovery Authentication Code Form が Disabled として含まれるようになりました。この機能を使用したい場合は、管理者が Alternative に切り替えることができます。

この 2FA 方式の詳細は、リカバリーコード を参照してください。

Passkeys にも使用される両方の WebAuthn 登録アクション (webauthn-register と webauthn-register-passwordless) は、アプリケーションによって開始された場合 (AIA)、skip_if_exists パラメーターをサポートするようになりました。

この変更により、ユーザーがすでに WebAuthn または Passkeys をセットアップしているシナリオで、AIA の使用がより便利になります。このパラメーターを使用すると、ユーザーがすでにそのタイプの認証情報を持っている場合にアクションをスキップできます。

詳細は、AIA を使用した WebAuthn 認証情報の登録 を参照してください。