A SaaS HR platform will authenticate city employees via the city’s identity provider. What must the architect manage for cloud federation?
Select an answer to reveal the explanation.
Short Explanation
When SaaS HR plugs into the city IdP, you are wiring trust—not inventing a second password pile. Lock down federation trust, check endpoints and signing keys, and ration attributes. Cleartext SaaS passwords, letting the vendor IdP the whole city, or skipping validation are cloud federation own-goals.
Full Explanation
Cloud federation for a SaaS HR platform authenticating city employees via the city’s identity provider requires a governed trust relationship: establish federation with the city IdP, validate endpoints and signing keys, and tightly control which attributes the SaaS receives. The municipality remains the authoritative identity source; the SaaS is a relying party consuming validated assertions under least-privilege attribute release.
Creating separate HR passwords unrelated to the city IdP and storing them in the SaaS in cleartext reintroduces credential sprawl and weak storage risk. Allowing the SaaS tenant to become an unconstrained identity provider for all city systems without review inverts trust boundaries. Skipping certificate and endpoint validation because “SaaS vendors are trusted” assumes integrity that must be verified continuously.
Exam caveat: cloud federation is still federation—validate crypto material and constrain attributes; vendor brand is not a substitute for trust configuration. Operational check: configure IdP→SaaS federation with validated keys/endpoints, minimize HR attribute release, prohibit cleartext parallel password stores, and review any attempt by SaaS to act as IdP for internal systems.