Some municipal apps remain on-premises while others are SaaS, yet leadership wants one coherent identity strategy. Which approach fits hybrid federation?
Select an answer to reveal the explanation.
Short Explanation
Hybrid identity is one conductor for two orchestras—on-prem and SaaS—following the same IdP sheet music. Keep policies and lifecycle unified where you can. Forever silos, double passwords everywhere, or orphaning cloud accounts when roles change break the hybrid story.
Full Explanation
Hybrid municipal estates—some applications still on-premises, others SaaS—need one coherent identity strategy. Use a consistent IdP-centric federation model so both on-prem and SaaS apps trust the same identity source and, where practical, unified authentication, authorization, and lifecycle policies. Centering identity on a governed provider (or tightly synchronized providers) reduces password sprawl, simplifies access reviews, and lets joiner–mover–leaver events propagate across hosting diversity instead of leaving cloud and on-prem entitlements out of sync.
Running disconnected identity silos forever with no federation bridges or shared lifecycle recreates the fragmentation hybrid IAM is meant to solve and doubles operational toil. Requiring separate usernames and passwords for every on-prem and SaaS app with no SSO options increases fatigue and weak password reuse across the portfolio. Disabling directory synchronization and orphaning cloud accounts when staff change roles leaves residual SaaS access after movers and leavers—one of the most common hybrid IAM failures in civic environments.
Exam caveat: hybrid success is measured by unified identity policy and lifecycle continuity, not by where each application is hosted. Operational check: point both on-prem and SaaS apps at the municipal IdP (or synced pair), enable SSO where appropriate, keep entitlement sync for cloud apps on role changes, and regularly audit for orphaned SaaS accounts after transfers and terminations.