SSO Rollout Meets the Legacy Lab
A university is consolidating 60 departmental applications behind a single SAML identity provider. Fifty-two apps migrated cleanly. Eight remain: three are on-premises research tools that only support header-based authentication from a local reverse proxy, two are SaaS vendors that require per-app local passwords, and three are lab instruments running embedded operating systems that cannot run a modern browser. The identity team proposes forcing all eight onto the IdP by standing up a password vault and a header-injection proxy. A security architect warns that the header-injection proxy effectively lets anyone who can reach it assert any username, and that the lab instruments would need shared credentials stored somewhere reachable on the lab network. Faculty are frustrated that logins still differ by system, and a phishing incident last term traced back to a reused local password on one of the SaaS apps. The steering committee wants a decision this month.
1. Evaluate the proposed vault-plus-proxy approach. Which parts are sound and which introduce unacceptable risk?
Read the worked answer
The proposal bundles two very different controls:
- Password vault for the two SaaS apps is sound. It removes the reused-local-password problem that caused the phishing incident, centralizes rotation, and can broker SSO without the vendor supporting SAML. Keep it.
- Header-injection proxy for the research tools is conditionally acceptable only if the proxy authenticates the user to the IdP first and then asserts identity downstream, and only if the proxy itself is not reachable by unauthenticated clients. The architect's concern is valid: a header proxy that trusts any caller is an authentication bypass. Mitigate by network-restricting the proxy, terminating TLS at the proxy, stripping inbound client-supplied identity headers, and logging every assertion.
- Shared credentials for lab instruments are the weakest link. Storing shared secrets on a reachable lab segment converts the instruments into a lateral-movement path. Prefer per-instrument credentials in the vault with brokered checkout, or network segmentation plus a jump host if the OS truly cannot do better.
Net: adopt the vault, harden and scope the proxy, and treat the instruments as a compensating-control problem rather than pretending they are SSO.
2. The committee asks whether '100% SSO' should be the success metric. Reframe the goal and propose measurable criteria.
Read the worked answer
'100% SSO' is the wrong target because it optimizes for a technology outcome rather than risk reduction, and chasing the last 13% can force exactly the risky workarounds described. Reframe the goal as 'every authentication is centrally mediated, observable, and revocable'-SSO is one means, not the end.
Proposed measurable criteria:
- Percentage of interactive logins that traverse the IdP or a brokered path (target rising, not necessarily 100%).
- Number of standing local passwords remaining, and rotation compliance for those that must exist.
- Mean time to revoke access across all 60 apps when a user leaves.
- Phishing-resistant MFA coverage for any app handling sensitive data.
- Count of shared/embedded credentials and whether each has a documented compensating control.
This lets the university declare success on the eight stragglers via vaulting, segmentation, and monitoring-without claiming SSO where it does not exist-and gives the auditor a defensible story. The metric shift also removes the incentive to deploy a permissive proxy just to hit a number.