A library multi-tenant SSO setup lets a user from one tenant open another tenant's account context after a misconfigured identity mapping. What theme should the tester frame?
Select an answer to reveal the explanation.
Short Explanation
SSO is supposed to be a trusted handshake, not a mix-up at coat check. When identity mapping is wrong, one tenant can wander into another's locker. Call the class — broken auth or SSO misconfig — without needing a vendor deep-dive.
Full Explanation
Broken authentication / SSO misconfiguration enabling cross-account or cross-tenant access is the correct theme when a library multi-tenant SSO setup lets a user from one tenant open another tenant’s account context after identity mapping errors. That failure breaks isolation between organizations or branches sharing the IdP—directly threatening patron privacy and institutional boundaries.
This is not benign cache warming. It is not merely a TLS cipher preference issue. DNSSEC validation failure is unrelated to identity mapping between tenants.
Exam caveat: multi-tenant SSO must bind tenant context server-side from authoritative claims, not from mutable client hints alone. CPTS auth testing includes cross-tenant session/object checks for civic shared platforms.
Operational check: attempt cross-tenant access with two library tenant test users, fix identity mapping and audience/tenant claims, add automated regression tests for isolation, and re-validate account context after login. Multi-tenant library SSO reviews should include explicit cross-tenant negative tests in every IdP configuration change checklist. Tenant isolation failures in library SSO are privacy incidents, not cosmetic IdP mislabels.