A healthcare company manages its SD-WAN Manager cluster with 40 operators who already use corporate Okta with MFA. Security requires centralized deprovisioning on job change, no local password vault, and full browser login to the Manager UI without per-device CLI accounts. Which external authentication approach best meets the centralized UI login requirement?
Select an answer to reveal the explanation.
Short Explanation
You spotted that browser login with MFA changes everything. SAML hands the whole login to your identity provider, so Okta handles proof and offboarding in one place.
Full Explanation
SAML SSO with Okta is correct because SD-WAN Manager supports SAML as an external identity provider for browser-based administrator sessions. It redirects UI login to Okta, where MFA, conditional access, and centralized disabling after a job change can be enforced, without storing passwords in Manager or managing per-device CLI accounts. RADIUS only for CLI logins on each WAN Edge fails by scope: the Manager browser UI remains on local accounts, and the approach adds the per-device accounts the requirements rule out. Integrating Manager with corporate LDAP fails by identity-source concept: a separate directory is not the Okta identity provider, so it bypasses the required Okta MFA and lifecycle management and leaves deprovisioning to another system. Syncing Okta users through SCIM fails by provisioning-versus-authentication concept: SCIM can create and disable accounts, but it is not a login method. Manager would still need its own credentials; SAML federates the login itself and meets the MFA and no-vault requirements. For exams, do not equate centralized user provisioning with browser SSO: SCIM manages accounts, while SAML federates browser UI login to the identity provider. Practically, verify that SAML is enabled in Manager with Okta metadata, that browser login enforces MFA, that a disabled Okta test user is rejected, and that operators have no active local passwords.