Section C · Identity & ops

Identity — Okta, Entra ID, Ping, Auth0

SSO, SCIM, service accounts, conditional access. Identity is the slowest part of most deployments because it routes through the customer's IT/security team, not the data team.

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.

The single biggest deployment risk

Of all the systems an FDE-DE integrates with, identity is the most-likely-to-slip. Plan for it. File early. Escalate when it stalls. The deployment timeline you committed to in the working agreement assumes identity is resolved by week 4. If it isn't, the timeline slips.

✓ Check yourself

Answer from memory before opening each one.

  1. Single sign-on works against the customer's sandbox but fails for real users in production. What does the chapter say is a common reason, and what do you check first?

    Show answer

    Sandboxes drift from production, so the production IdP application may not match what you tested. Check the attribute mapping and group claim names in the production configuration against the sandbox. See why identity is the long pole and SSO.

  2. A user leaves the company and still has an active account in your platform three weeks later. What failed, and what does the fix need on each side?

    Show answer

    Provisioning was manual, so off-boarding was forgotten. With SCIM, the IdP deactivates the user as soon as they leave. Your platform exposes /scim/v2/Users and /scim/v2/Groups, and the customer's IdP team configures provisioning with your SCIM URL and token. See SCIM.

  3. Your platform supports only OIDC, because it is the cleaner protocol. What goes wrong in enterprise deals?

    Show answer

    SAML is still the default for enterprise SSO at most customers, and the customer's IdP team chooses the protocol they are comfortable with. Supporting only one narrows who can sign. Support both. See SSO.

  4. Your pipeline runs in AWS and must read a customer's GCP project. Rank the service-account options by security and by setup cost, and say when you would settle for less.

    Show answer

    Workload Identity Federation is the strongest and the most complex. Mutual TLS is strong with more setup, and OAuth2 client credentials are cleaner than a long-lived token. A plain API key or token is simplest, and customers often accept it for warehouse access. Choose by what the customer's security review will approve in the time you have. See service accounts.

  5. Credentials for your integration are correct, and still your service-account login to a customer's Entra tenant starts failing. What do you check?

    Show answer

    Conditional Access policies, such as device trust or geographic restrictions, which can block service-account authentication. The same applies in Okta. Ask the admin whether a policy changed. See Entra ID and Okta.

  6. It is week 1 of a deployment. Which identity tickets do you file, what goes in each, and when do you escalate?

    Show answer

    File the SSO ticket (SAML metadata URL, expected attributes, group claim names), the SCIM ticket (endpoint URL, tested provider configurations, group mapping) and a service-account ticket for each system-to-system link. Set a 7-day check-in. If a ticket sits for two weeks without action, escalate through your account executive. See the identity playbook.

Takeaway

  • Identity is the likeliest thing to slip, because the work sits with a small IT or security team whose queue is long, and not with the data team you talk to daily.
  • Support both SAML and OIDC, since the customer picks whichever their IdP team knows best.
  • SCIM makes off-boarding automatic, and without it ex-employees keep accounts that nobody remembers to close.
  • Service accounts range from long-lived tokens to Workload Identity Federation, and the right choice is the strongest one the customer will approve in time.
  • Conditional Access in Entra and Okta can block an integration that worked yesterday, so ask about it before you debug code.
  • File identity tickets in week 1, track them in the weekly status document, and escalate after two quiet weeks.

Once users and services can sign in, the last piece is how you watch the pipeline and who gets paged. → Observability and ops

Further reading