Enterprise identity for SaaS

Enterprise SSO built into your product

Answer Yes to the identity rows on your customer's security review. It asks for single sign-on (SSO) with its own company login over SAML, plus SCIM provisioning, roles, MFA and audit evidence.

SAML is the standard that carries that company login into your product. Our SSO integration services build each of those into your SaaS product, on the identity platform that fits it, with the audit evidence attached.

Start with a scoped call

Send your customer's open identity rows. A software engineer goes through them and the route with you; expect a reply within one business day.

How we handle what you send is set out in our privacy notice.

The deal is waiting on a row you cannot tick yet

The request for SSO came from the customer you are trying to sign, not from your roadmap.

Your customer asked, not your roadmap

Your enterprise customer wants to sign in through its own identity provider (company login), which smaller customers never asked for. Answering No can end the deal.

One of your few software engineers goes quiet

SAML, provisioning and roles pull someone off the product for time you did not plan. The deal sits on your desk meanwhile.

A mistake here exposes your customers

Sign-in sits in front of every customer's data. Get it wrong and the cost is their data, not a broken screen.

What each identity row on the review asks for

Each piece of identity work answers named rows in SOC 2 and ISO/IEC 27001, the frameworks your customer's reviewer uses.

What each identity row on the review asks for
Identity workSOC 2 criterionISO/IEC 27001:2022 Annex A
Enterprise SSOCC6.1: logical access, where users are identified and authenticatedA.5.17 Authentication information; A.8.5 Secure authentication
MFA and passkeysMapped instead to CSA CCM v4 strong authentication: MFA at least for privileged usersA.8.5 Secure authentication
SCIM provisioning and offboardingCC6.2: register users before access, remove credentials when access endsA.5.16 Identity management; A.5.18 Access rights
Roles and permissionsCC6.3: access granted and changed by role, with least privilegeA.5.15 Access control; A.8.2 Privileged access rights
Access reviewsCC6.3 point of focus: Reviews Access Roles and RulesA.5.18 Access rights
Sign-in and admin logsAsk your customer which criterion they test it underA.8.15 Logging

Find the rows they asked about and you have the scope for this deal. Frameworks such as CSA CCM add one more: MFA at least for every privileged user.

SOC 2 criteria paraphrased from AICPA TSP section 100. ISO/IEC 27001:2022 control titles only. Whether you pass is your customer's and their auditor's decision; we build the controls and the evidence, and we do not certify.

Where SAML libraries keep breaking

The hard part of SAML is checking the signature on every assertion, and widely used SAML libraries have repeatedly shipped flaws in that check. In CVE-2024-45409, scored 10.0 by GitHub and 9.8 by NVD, anyone holding one signed document from the identity provider could forge an assertion and sign in as any user. GitLab's 17.3.3 security release said that turning on MFA at the identity provider does not stop it.

Show data table
Our count of critical advisories listed in the GitHub Advisory Database and NVD.
Item Critical advisories
ruby-saml 6
xml-crypto 2
node-saml / passport-saml 2
samlify 1
python-saml 1
saml2-js 1
omniauth-saml 1
Shibboleth XMLTooling-C 1
GitHub Enterprise Server 1

Ask whoever builds your SAML how signature validation is tested.

Critical SAML signature and assertion-forgery advisories, by library or product, 2018 to December 2025 Our count of critical advisories listed in the GitHub Advisory Database and NVD. GitHub Advisory Database and NVD

Have your customer's questionnaire open?

Bring your customer's questionnaire to the call. We start from your customer's actual identity rows and tell you which ones need building.

Book the scoped call

You get a reply within one business day.

Buy a platform, self-host, or extend your own auth

Which route fits your product? Four questions pick it: how many customers need their own connection, whether your current provider lets you export password hashes, who carries the uptime, and where your users live today.

  • A hosted identity platform

    Fits when

    Many customers will need their own connection, your team is small, and you do not want to run identity servers.

    What you take on

    Pricing can grow per connection. Some platforms will not export password hashes if you leave, and an outage takes sign-in down for every customer.

  • A self-hosted identity server

    Fits when

    You want the user store and the password hashes in your own hands, and you can carry the uptime.

    What you take on

    You run, patch and monitor the identity server yourself. You also carry its uptime for every customer that signs in through it.

  • Extend your own auth

    Fits when

    Your users already live in your own database or provider, and only a few enterprise customers need their own connection.

    What you take on

    The per-customer setup and the screens your customer's IT admin uses, which is where much of the work sits.

The protocol is rarely the slow part. Typesense's own write-up of building SAML says the protocol worked by week three, and the rest of the effort went into the self-service setup screen and the docs.

We have delivered client work on Keycloak (a sign-in server you host yourself), Clerk and WorkOS. When you or your customer already runs Auth0, Okta or Microsoft Entra ID, we integrate with it. Identity work we have delivered includes a life-sciences research SaaS, whose authentication flow we secured with WorkOS; an RFID SaaS platform, on Keycloak; an awards platform, on Clerk; and a regulated cannabis delivery platform, on Keycloak.

For what the platforms charge, see what identity platforms charge. The figures there are third-party and dated.

The platform you pick shapes how you can price SSO

Of the 104 vendors on the sso.tax list with a published uplift, 73 at least double the price to include SSO. Per-connection identity costs can push a SaaS into doing the same. So the route you pick shapes whether SSO can sit in a plan your mid-market customers will actually buy, and some of them require SSO and SCIM without ever buying an enterprise plan.

Show data table
Covers only the 104 vendors that charge for SSO with a published uplift: median 150%, middle half 80% to 354%.
Item Value
Under 100% 31 vendors
100% to 299% 43 vendors
300% or more 30 vendors
Price increase from the base plan to the cheapest plan that includes SSO Covers only the 104 vendors that charge for SSO with a published uplift: median 150%, middle half 80% to 354%. sso.tax, vendors listed with a published SSO uplift, as of June 2026

What we build, with SCIM provisioning in full

  1. Layer 1

    Sign-in

    Per-customer enterprise SSO over SAML and OIDC. Multi-tenant login (each customer signs in through its own identity provider, kept apart from every other customer).

    Hands upward

    A verified user and the customer organisation they belong to

  2. Layer 2

    SCIM provisioning

    Your customer's directory creates, updates and removes users in your product. It gets the most space: this row decides whether someone who left loses access.

    Hands upward

    Users your customer's directory created, updated or removed, with leavers cut off

  3. Layer 3

    Roles, MFA and passkeys

    Role-based and attribute-based permissions, mapped to how your customer organises access. MFA and passkeys for the accounts that need them.

    Hands upward

    A role and its permissions, mapped to how your customer organises access

  4. Layer 4

    Audit evidence

    Sign-in and admin audit logs, access reviews and offboarding records, kept in a form your customer's reviewer can sample.

    Hands upward

    Logs, reviews and offboarding records in a form your customer's reviewer can sample

The identity layer sits in front of your product and hands each request a verified user, organisation and role.

Your customer's directory creates, updates and removes users in your productSCIM is the row that decides whether someone who left loses access.
Per-customer enterprise SSO over SAML and OIDCEach customer signs in through its own identity provider, kept apart from every other customer.

Where SCIM breaks, per the identity provider's own docs: Microsoft documents that Entra ID deactivates a user by setting active to false instead of deleting them, so the endpoint has to support soft delete and restore, and that Entra sends PATCH operation names in varying case. Much of the effort goes into that provider-specific setup.

How the work runs, and what you approve

Our enterprise SSO work runs on the same published process as any Atyantik engagement. Delivery runs against the scope you agreed, and you approve every change before it enters the plan. Your IP, your hosting and your accounts are yours from day one, and if you move the work in-house or elsewhere, you get a written runbook. Whoever you hire, settle three questions before the build: who answers when one of your customer's users cannot sign in, what break-glass access exists if the identity provider connection fails, and how existing password users are linked to their company identities.

  1. 01

    First call

    You bring your customer's review rows to the call, and we start from them.

    You receive

    A technical person on the call, within one business day on request

  2. 02

    Discovery and specification

    For identity work, the rows, the route and your customers' identity providers are written down here.

    You receive

    BRD, FRD, SRS and TRS, at the depth the project needs

  3. 03

    Milestone planning

    Each milestone states what has to be true for it to count as done.

    You receive

    A milestone plan, each milestone carrying its own documented exit criteria

  4. 04

    Execution

    Delivery runs against the scope you agreed, in milestones, each checked against its documented exit criteria.

    You receive

    Milestones delivered against the agreed scope, each with its documented exit criteria

  5. 05

    Changes

    You approve each change note first. Nothing in the build moves on a re-scope you have not accepted.

    You receive

    A change note for every change, with time, effort and cost laid out

For the project phase by phase, see how an SSO project breaks down. Its ranges are third-party and dated.

70%fewer authentication-related support tickets

Measured, from the Keycloak SSO migration case study

One sign-on for a running set of applications

  1. -70%Authentication-related support tickets

    Measured: a software vendor operating a suite of separate applications fronted them with Keycloak. Sign-in uses OAuth 2.0, OpenID Connect (sign-in standards) and MFA.

    Evidencethe support-ticket figure in the case study

  2. several to 1Separate application logins

    Measured. The same software vendor replaced each application's own login with one Keycloak sign-on that covers every application in the suite.

    Evidencethe sign-on change in the case study

  3. thousandsMonthly active users

    Described. The software vendor's users, thousands of them each month, sign in once through the one Keycloak service.

    Evidencethe user count in the case study

  4. 0Applications taken down

    Described. The software vendor's user data moved from each application's own database into one store while every application kept running.

    Evidencethe no-downtime move in the case study

A software vendor operating a suite of separate applications moved its users onto one sign-on on Keycloak, with MFA, and with OAuth 2.0 and OpenID Connect (open standards for sign-in and access). This was the vendor's own applications brought under one sign-on, not a multi-tenant login for its customers. What it shows is the retrofit: moving live users onto a new sign-on without taking the applications down.

The method, the stack and the evidence behind each figure are in the full case study.

When we are the wrong call

We fit when

  • You run a SaaS product, and your enterprise customers need their own sign-in, provisioning, roles and evidence inside it.

Go elsewhere when

  • You are rolling out SSO for your own staff: that is workforce identity and access management services, and your identity provider's vendor or an IAM consultancy will serve you better.
  • Your platform already covers the rows and you only need them switched on, so its own docs and admin tools will get you there faster than a call with us.
  • You need an attestation or a certification: that is an audit firm's job, since we build the controls and the evidence and do not certify.

Before you book the call

Who answers when one of our customers cannot sign in?
Who answers your customer's users when sign-in fails is a decision to make before the build, with whoever builds it, alongside the break-glass access an admin uses if your customer's identity provider connection fails. Both are among the three questions in the steps above. After launch, changes on an ongoing maintenance arrangement go through a change note too, with time, effort and cost laid out before you approve.
Will our existing users have to reset their passwords?
Whether your users reset their passwords depends on whether your current provider lets you export password hashes. If it does, and the new platform supports that hash format, users move as they are. If it does not, a drip migration moves each user the next time they sign in, so active users are not forced through a reset.
Is OIDC enough, or do we need SAML?
Enterprise customers still ask for SAML. We build both, and each customer organisation gets whichever protocol its identity provider uses.
Can you work with the Auth0 or Okta we run, or our customer's Microsoft Entra ID?
Yes, we integrate with Auth0, Okta and Microsoft Entra ID when you or your customer already runs one. Whether to keep it is what the four route questions above decide, and the choice is yours.
What will enterprise SSO cost us?
We do not publish a price for enterprise SSO work, because six things move it: how many customers need their own identity provider connection, SCIM on top of SSO, linking existing password users, roles drawn from the customer's directory groups, the audit evidence the reviewer asks for, and any hosted auth platform you already sit on. For numbers, see our posts on what identity platforms charge and on how an SSO project breaks down; both carry dated third-party figures. Delivery runs against the scope you agreed, and any change comes as a change note with time, effort and cost laid out first.

what identity platforms charge

Should we build enterprise SSO ourselves?
Sometimes, yes: with one or two enterprise customers and a software engineer who has the time, extending your own auth can be the right call. Typesense's own write-up of building SAML found the protocol worked by week three and the rest went into the self-service setup screen and the docs. Whoever builds it, ask how signature validation is tested, because that is the flaw behind the advisories above.

Bring your customer's review to the call

Bring your customer's security review, or just the identity rows on it. A software engineer goes through your rows and the route that fits your product with you. Either you go ahead on the process above, against a scope you agree, or you leave with that conversation and your own team builds it.

Security work beyond identityAPI and system integrations
Tirth Bodawala, Chief Technology Officer of Atyantik Technologies
Tirth BodawalaChief Technology Officer, Atyantik Technologies
  • A reply within one business day
  • A call with a software engineer
  • Every change approved by you before it enters the plan

How we handle what you send is set out in our privacy notice.