Identity — Okta, Entra ID, Ping, Auth0

Why identity is the long pole

Of the dozen failure modes in the FDE-DE playbook, identity bottlenecks are the most common. Reasons:

• Identity changes route through the customer's IT or security team, not the data team you're working with day-to-day.
• IT teams are smaller and more constrained than data teams; their queue is longer.
• Security review on a new SSO connection is non-trivial — sometimes 4–6 weeks.
• SCIM provisioning requires testing in the customer's identity sandbox; sandboxes drift from production.
• Service-account provisioning requires explicit policy approval at many enterprises.

File identity tickets in week 1, before you need them, with explicit ownership and timeline asks.

SSO (SAML / OIDC)

The customer's IdP authenticates users into the platform's UI.

SAML

Older protocol; XML-based assertions. Widely supported. The default for enterprise SSO at most customers.

OpenID Connect (OIDC)

Modern OAuth2-based; JSON tokens. Cleaner than SAML; growing as the default for newer integrations.

For a contract-intelligence platform, supporting both is table stakes. The customer picks based on what their IdP team is most comfortable with.

Setup steps

1. Platform-side: define the SAML/OIDC application in your SSO provider.
2. Customer-side: their IT team creates the corresponding application in their IdP (Okta, Entra ID, etc.).
3. Exchange metadata XML or OIDC configuration JSON.
4. Configure attribute mapping (email, name, groups).
5. Test with a real user in the customer's sandbox; promote to production.

SCIM provisioning

System for Cross-domain Identity Management. Lets the customer's IdP automatically create / disable platform users as employees join / leave.

The lifecycle:

• New employee joins → IdP provisions a platform user.
• Employee changes role → IdP updates their group membership; platform-side permissions adjust.
• Employee leaves → IdP deactivates the user immediately.

SCIM is what makes audit-trail-clean access management possible at enterprise scale. Without it, customers maintain platform users manually — and forget to off-board, leaving accounts active for ex-employees.

Setup steps

1. Platform exposes SCIM endpoints (/scim/v2/Users, /scim/v2/Groups).
2. Customer's IdP team configures provisioning, providing the platform's SCIM URL + token.
3. Test with a sandbox user.
4. Enable group-based access rules.

Service accounts

For machine-to-machine traffic: your pipeline → customer's warehouse, your pipeline → customer's CLM, etc.

Patterns

• API keys / tokens: simplest; customer's IT issues a long-lived token. Often acceptable for warehouse access.
• OAuth2 client-credentials: cleaner. The customer registers an OAuth app; you authenticate with client_id + client_secret.
• Mutual TLS: certificate-based. Higher-security; more setup overhead.
• Workload Identity Federation: for cloud-to-cloud (your AWS service to their GCP project, for example). Strongest security; most complex setup.

Approval timeline

Service-account provisioning at most enterprises requires:

• A formal request through their IT ticketing system.
• Approval from a manager (sometimes a security committee).
• Provisioning by the IdP team.
• Communication of credentials through a secure channel.

2–4 weeks is typical. File in week 1.

Okta

What it is

Independent IdP; most common at mid-to-large enterprises. Polished admin UX; widely supported by SaaS platforms.

Integration

• SAML and OIDC both well-supported.
• SCIM provisioning supported.
• Okta's Universal Directory often the source of truth for the customer's identity.

Gotchas

• Customer's Okta admin is usually one person; their queue is the bottleneck.
• Conditional Access policies (device trust, geo restrictions) can block your integration unexpectedly.

Microsoft Entra ID (formerly Azure AD)

What it is

Microsoft's IdP; bundled with Microsoft 365. Default at Microsoft-shop enterprises.

Integration

• SAML and OIDC supported.
• SCIM provisioning supported but sometimes less polished than Okta's.
• App Registrations for OAuth2 client integrations.

Gotchas

• Multi-tenant scenarios (cross-tenant access) need careful App Registration setup.
• Conditional Access policies common; can block service-account authentication.
• Confusing UI for less-frequent admin operations.

Ping Identity

What it is

Enterprise IdP, common in regulated industries (finance, healthcare) and large government.

Integration

• SAML and OIDC supported.
• SCIM supported.
• Less polished UI than Okta; more enterprise-y.

Gotchas

• Older deployments (PingFederate on-premises) require network connectivity into the customer's data center.
• More variation in setup patterns; rely on the customer's PingFederate team.

Auth0

What it is

Developer-friendly IdP, now Okta-owned. More common at smaller / younger customers and at platforms that need an IdP for their own user base.

Integration

• OIDC-first.
• SAML supported.
• SCIM supported via extensions.

Gotchas

• Less common at large enterprises as the corporate IdP.
• Pricing tiers gate features; some customers may not have SCIM.

The identity playbook

Concrete actions in week 1:

1. Ask the customer's data lead: "Which IdP do you use? Who's the admin?"
2. File the SSO setup ticket with the IT team. Include: platform's SAML metadata URL, expected attributes, group claim names.
3. File the SCIM provisioning ticket. Include: SCIM endpoint URL, tested provider configurations, group mapping.
4. File the service-account ticket for any system-to-system integrations (warehouse, CLM, etc.).
5. Set a 7-day check-in with the IT team to verify tickets are progressing.
6. Track all identity tickets in your Friday status doc until resolved.

If a ticket sits for 2+ weeks without action, escalate to your AE — they may need to involve the customer's IT director through commercial channels.