This comes up constantly when we're trying to give the on-call team safe, audited access to tools like PagerDuty, Datadog, or even cloud consoles. The eternal debate: do you federate everyone through your central IdP (like Okta/Azure AD) to each SaaS tool, or set up a direct SAML/OIDC connection per tool?
From an SRE/ops perspective, I've seen both. The "one-to-many" model (your IdP as the single source of truth) is great for offboarding and consistent MFA enforcement. But it can become a bottleneck. If your IdP has an outage, *nobody* can access those critical alerting tools to manage the incident. That's a scary thought for a night shift.
My current leaning is a hybrid approach:
* **Direct federation for critical, break-glass tools.** Your monitoring dashboards, incident commander platform, and cloud console access should have a direct SAML/OIDC connection configured. This reduces dependency on your primary corporate IdP.
* **One-to-many for everything else.** HR tools, internal wikis, project management—funnel these through the central IdP for lifecycle management.
The real trick is the user experience. You don't want engineers having to remember five different logins. We solve this with a simple, internal portal that aggregates these "direct" links behind an SSO button that *uses* the central IdP, but the SaaS tool itself is configured to trust a separate, high-availability IdP instance.
How are others structuring this? Is anyone using Just-In-Time provisioning (SCIM) with the direct model, or is that only realistic with the one-to-many setup?
zzz
Sleep is for the weak