MFA登録ポリシー
アップグレード後にMFA登録ポリシーがどのように変わるのかを説明します。
変更の概要 | MFA登録ポリシーは、現在はAuthenticator登録ポリシーと呼ばれます。 |
管理者のエクスペリエンス |
アカウント復旧のシナリオでは、次の考慮事項が適用されます。
電話Authenticatorには、SMSと通話の2つの方式があります。いずれか(または両方)の方式を使用可能にする場合、ユーザーは電話Authenticatorを登録する必要があります。 SMSと音声はどちらも電話Authenticatorの方式ですが、ポリシーでは個別に表示されます。いずれかの方式を使用する場合、ユーザーは電話Authenticatorに登録する必要があります。 ユーザーの復旧方法としてメールまたは電話を選択した場合、または追加の検証として秘密の質問を選択した場合、認証登録ポリシーで無効化されている場合でも、OktaはこれらのAuthenticatorへの登録をユーザーに求めます。 メールをオプションのAuthenticatorにできます。「メールをオプションのAuthenticatorにする」を参照してください。 Classic EngineのMFA登録ポリシーがOkta VerifyのTOTP(時間ベースのワンタイムパスワード)にユーザーグループのみを登録する場合、このグループはアップグレード後にTOTPとPushの両方に登録されます。Identity Engineでは、Okta Verifyを必要とするAuthenticator登録ポリシーは、 で構成した任意の検証オプションへの登録を自動的にトリガーします。 SSPR(セルフサービスパスワードリセット)のシングルサインオンが有効化されていない場合、これらのポリシーに表示されるAuthenticatorは、Authenticator登録ポリシーには表示されません。 SSPRにメール、秘密の質問、または電話のAuthenticatorが必要な場合、登録要件が異なります。
最初のチャレンジで登録するアクションと、サインリンフローで登録するアクションは、区別されなくなりました。必須のAuthenticatorがないユーザーは、アプリへのサインイン時に必須Authenticatorへの登録を求められます。 Oktaへのサインイン時にユーザーは、管理者が必須として設定したすべてのAuthenticatorへの登録を求められます。 アプリへのアクセス時にユーザーは、アプリの認証ポリシーで必要とされるすべてのAuthenticatorへの登録を求められます。 所有要素タイプを備えたMFAをアプリが必要とする場合、それらのアプリへのアクセス時にユーザーは、該当するAuthenticatorへの登録を求められます。これらのAuthenticatorがAuthenticator登録ポリシーで任意である場合でも、ユーザーは登録を求められます。「多要素認証」を参照してください。 初回のアカウントセットアップ時にユーザーは、Authenticator登録ポリシーとセルフサービス復旧ポリシーで必要とされるすべてのAuthenticatorへの登録を求められます。初回のアカウントセットアップでは、Oktaは両方のポリシーを同時に評価します。それ以後のサインインイベントでは、Oktaは通常の処理ルールを適用します。Oktaは、これらのポリシーの間でAuthenticatorをプールしなくなりました。 パスワードなしサインインエクスペリエンスが有効な場合、またはユーザーがソーシャル認証またはインバウンドフェデレーションを認証に使用する場合を除き、パスワードAuthenticatorが構成され、常に求められます。 |
ユーザーエクスペリエンス | Classic EngineのOkta Verify TOTPにのみ登録されているユーザーは、Okta VerifyアカウントをIdentity Engineにアップグレードすると、Okta Verify TOTPとPushの両方に登録されます。 |
関連項目 | Authenticator登録ポリシー |