Signing in with your company identity provider (SAML SSO)

Umamy supports enterprise single sign-on through SAML 2.0. Your team signs in with your own
identity provider — Microsoft Entra ID, Okta, Google Workspace, or any SAML 2.0 provider — and
new employees get access on their first sign-in, with no invitation to send.

Setting it up takes three things: your IT team configures an application on their side, you
tell us your identity provider's metadata URL, and you prove the email domains your provider
speaks for. Nothing is enforced until you ask us to switch it on.

What your IT team needs from us

Umamy is the service provider (SP). These are its values:

The same values are shown on Settings → Single Sign-On in Umamy, with copy buttons. Read
them there rather than from this page if the two ever disagree — that page is generated from
the live configuration.

What we need from you

1. Your identity provider's SAML metadata URL (preferred) or its metadata XML file. You can

enter it yourself on Settings → Single Sign-On.

2. The email domain(s) that appear in your assertions. This is the one detail that most

often goes wrong: the domain in your contact addresses is not always the domain your
provider asserts. Send us the exact domain your users' NameID will carry, and every
additional domain (subsidiaries, aliases) that should sign in.

3. Attribute names for email and full name, if they differ from the Entra ID defaults

(http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress and .../claims/name).

Configuring Microsoft Entra ID

1. **Entra admin center → Enterprise applications → New application → Create your own

application.** Name it Umamy, choose *Integrate any other application you don't find in
the gallery (Non-gallery)*.

2. Single sign-on → SAML.
3. Basic SAML Configuration → Edit:

• Identifier (Entity ID) → the Entity ID from the table above.
• Reply URL (Assertion Consumer Service URL) → the ACS URL.
• Sign on URL → https://app.umamy.io/sign-in (needed only for IdP-initiated sign-in).
• Logout URL → the SLO URL.

4. Attributes & Claims. The default Entra claim set already carries email and name; leave it

as is unless your tenant has been customised. Make sure the *Unique User Identifier (Name
ID)* is the user's email address.

5. Users and groups → assign the people or groups who should have Umamy access. Umamy

creates their account on first sign-in; there is nothing to pre-provision on our side.

6. Take the App Federation Metadata Url from the SAML Certificates section, and enter it

on Settings → Single Sign-On.

Okta and Google Workspace follow the same shape: create a custom SAML app, set the Entity ID and
ACS URL, make the NameID the email address, and supply the metadata URL (Google Workspace only
offers a metadata file — that is fine, send it to us).

Verifying your email domains

Once your identity provider is registered, an admin of your Umamy workspace adds each domain on
Settings → Single Sign-On and publishes a TXT record to prove control of it:

Then click Verify. DNS propagation usually takes a few minutes.

A domain does nothing until it is verified: it is not used to route logins, and it does not grant
anyone access. That is deliberate — verification is what makes it safe for you to declare your
own domains rather than filing a ticket with us for each one.

What happens on first sign-in

A user who authenticates through your identity provider is added to your workspace
automatically, as a member. If someone had already been invited as an admin, that
invitation's role is kept — arriving through the provider first does not demote them.

Once SSO is switched on for your workspace, **entering it requires a session established through
your identity provider**. Someone with a session obtained another way is asked to reconnect
through it.

This is enforced at the workspace boundary, not at sign-in. If one of your people also belongs
to a different Umamy workspace — a partner's, say — that workspace is unaffected and stays
reachable. We do this on purpose: your SSO policy governs your data, and should not be able to
lock someone out of an unrelated organization's.

Limits worth knowing before you sign off

• No SCIM / automatic deprovisioning. SAML carries no "this user has left" signal. Removing

someone from your identity provider stops them signing in, but their Umamy membership, any API
keys they created, and any session they already hold remain until removed. Revoke access in
Settings → Team members. If automated deprovisioning matters to you, tell us — SCIM is a
separate piece of work, not a setting.

• No single logout wiring. The SLO endpoint exists, but signing out of Umamy does not sign

you out of your identity provider, and vice versa.

• Session lifetime is a platform-wide setting, not a per-customer one. If your security

policy requires a specific maximum session length, raise it with us rather than assuming it can
be configured for your tenant alone.

• API keys are not subject to SSO enforcement. They are machine credentials, issued and

revoked separately in Settings → API keys. Turning SSO on does not break your integrations,
and equally does not gate them behind your identity provider.

Troubleshooting

"No single sign-on is configured for this domain." The domain you typed is not a verified
domain of a registered provider. Check the exact spelling, and that the domain has been verified
on Settings → Single Sign-On — an added-but-unverified domain gives this message.

A domain shows "Not routing logins yet". It is proven, but our identity service has not
accepted it yet, so signing in through it will fail. Contact us — this is ours to repair, and
takes a moment.

Sign-in works, but the person lands nowhere. Their asserted email domain is probably not one
of your verified domains. This is the mismatch described above: check what your provider actually
puts in NameID, not what your contact addresses look like.

Updated on: 24/08/2026