Residents must maintain twenty separate logins for related city services. How should single sign-on be applied?
Select an answer to reveal the explanation.
Short Explanation
Twenty city logins feel like a keyring that never fits the door—SSO can unify them, but only if the front door stays strong. Match authenticator strength to the riskiest app in the circle; a shared four-digit PIN or “SSO means no auth” just paints a target. Renaming the portal without actually federating helps no one.
Full Explanation
Single sign-on across related city services should reduce the burden of twenty separate resident logins while preserving authentication assurance appropriate to the most sensitive application in the SSO domain. Introduce SSO so residents authenticate to a governed identity provider once, then access related services under unified session and policy controls—without weakening authenticators to the lowest common denominator. If one service in the circle holds higher-risk data, MFA or equivalent strength at the IdP (or step-up authentication) must still protect that risk.
Implementing SSO with a single shared four-digit PIN for every resident and every service collapses assurance to something trivially guessable and shared across the entire portfolio. Eliminating authentication entirely once SSO branding appears on the portal confuses marketing labels with controls and opens every service behind a logo. Forcing residents to keep twenty passwords while merely renaming the portal “SSO Experience” delivers no federation or session benefit and leaves password fatigue intact.
Exam caveat: SSO centralizes authentication UX and policy; it does not authorize dropping MFA or replacing credentials with weak shared PINs. Operational check: federate related city services to a common IdP, set authenticator strength to the highest risk in the SSO circle, enable step-up where needed, measure reduction in per-app passwords, and confirm branding changes alone are not counted as SSO.