This is a financial & insurance problem we approach through our Platform to Platform service line.
The problem
Your platform manages its own users. It has a password policy, a roles table, an invitation flow, and it works.
Then an enterprise client’s security review arrives, and the requirement is not negotiable: authentication goes through their identity provider, access is governed by their directory groups, and a person leaving the organisation loses access to your platform without anyone emailing you. In a regulated firm this sits alongside segregation-of-duties evidence and an access review the auditor will sample.
The deal stalls. Not on features, on identity. And the estimate your team produced assumed the work was “add SAML”, which is the smallest part of it.
Why it’s hard
The protocol is the easy half. SAML 2.0 and OIDC are well specified with mature libraries. Authentication can be working in a fortnight. What takes the remaining time is everything that decides what the authenticated person is allowed to do, and what happens when they should no longer be allowed to do it.
Group-to-role mapping does not generalise. Every client models their directory differently. One sends a flat list of group names, one sends distinguished names, one sends a custom claim, one sends nothing useful and expects you to infer role from an email domain. A single hard-coded mapping means the second client is a code change, and the fifth is a maintenance problem.
Account linking is a takeover risk. Migrating existing local accounts to federated identities means matching them, and the obvious key is email address. If the identity provider’s email claim is not verified, or a client’s directory allows an alias that matches an existing local account, matching on email hands over that account. This is a real and repeatedly exploited failure mode, and it is the one to design against first.
Deprovisioning is the control that is actually tested. Authentication is visible when it breaks. Deprovisioning fails invisibly: the leaver simply keeps working. Auditors know this, which is why SCIM or a scheduled directory reconciliation is what they ask for evidence of.
Sessions outlive the assumptions. Operator consoles hold long sessions because the work is continuous. Federated identity introduces session lifetime, token refresh and single logout semantics that have to be reconciled with that reality. Silent revocation of an operator’s session mid-task is a production incident; never revoking is a control failure.
A multi-tenant platform needs identity per tenant. Several clients, several identity providers, and users who must be routed to the right one before authenticating. Home-realm discovery, per-tenant provider configuration, and strict audience validation so a token issued for one tenant cannot be presented to another.
IdP-initiated SAML is where the sharp edges live. Unsolicited assertions, replay windows, audience and recipient validation, signature verification on the assertion rather than only the response. Libraries default to permissive behaviour more often than they should.
The audit trail has to survive federation. Every privileged action needs to name the identity that performed it, in a form that still resolves after the user has left the client organisation. A foreign key to a directory record that no longer exists is not an audit trail.
How we approach it
Separate authentication from authorisation, explicitly. The identity provider asserts who someone is. The platform decides what they can do. Collapsing those two into one layer is what makes the second client integration painful, so the role model stays ours and the mapping into it is data.
A per-tenant claim mapping table, not code. Directory groups and claims map to platform roles through configuration held per tenant, with every mapping change recorded. Onboarding a new client’s identity provider becomes a configuration exercise with a test path, not a release.
OIDC by preference, SAML 2.0 where required. Both supported, with strict validation: signature, audience, recipient, replay protection and clock skew handled deliberately rather than left at library defaults.
SCIM for lifecycle, with reconciliation behind it. Provisioning, deprovisioning and attribute updates pushed from the directory where the client supports SCIM. Where they do not, a scheduled reconciliation against the directory catches drift. Either way, the control produces evidence.
Linking only on a verified claim, with an explicit migration. Existing local accounts are linked to federated identities through a deliberate, logged migration using verified identifiers, never through implicit email matching at first login. Unmatched accounts are handled by an administrator rather than guessed at.
MFA delegated, not duplicated. The identity provider owns the second factor. Implementing a competing MFA inside the platform means two enrolment paths and two recovery paths, and recovery paths are where accounts get stolen.
Break-glass access, designed and noisy. A small number of local administrative accounts that work when the identity provider does not, protected by hardware keys, alerting on every use, and reviewed afterwards. Any organisation that says it does not need this has not yet had an identity provider outage.
What we would not do. We would not build an identity provider. We would not accept an unverified email claim as a join key. And we would not ship federated login without the deprovisioning path in the same release, because the gap between them is exactly the finding the next audit will report.
What it takes
A named contact in the client’s identity team. Most schedule slippage on these projects is waiting for someone with access to the directory configuration.
Their group model, in writing, before build. Which groups exist, what they mean, which claims will be sent, and who owns changes to them.
A test tenant on their identity provider. Testing against production directories is not acceptable to their security team and should not be acceptable to yours.
A decision on session lifetime and forced re-authentication. This is a business decision about operational continuity versus revocation speed. It needs to be made by someone who can be accountable for it.
A migration plan for existing accounts, including what happens to accounts that do not match anything in the directory.
Where this has been done
This is a capability description, not a shipped reference. Enterprise SSO integration work has been delivered, but we hold no published detail on it, so this page claims no client, no date and no figures.
What is separately documented is the adjacent work. The multi-tenant platform we built and operate handles per-tenant configuration, role-based operator access, and audited privileged actions with operator, timestamp and prior value recorded against every override. That is the same structural problem set as federated identity in a multi-tenant product, and it is where the judgement above comes from.
If you are evaluating us for this, the useful conversation is about your identity provider, your group model and your deprovisioning evidence requirement. Bring those and the estimate will be real.