SAML 2.0 single sign-onEarly access

Enterprise single sign-on, in both directions

Let a customer's identity provider sign their people in to your app, or make your app the identity provider for the tools your customers use. Signed, replay-checked and routed by the email domain they have proved they own.

Book a demo How discovery works

SAML connection · Vaarta AIEarly access

Identity providerCustomer IdP

Routes people fromvaarta.ai, verified by DNS

Assertionssigned, RSA-SHA256

New peoplejoined as member

Group ruleadmins → Admin

People who type a vaarta.ai address are sent to this connection.

Why it matters

Your enterprise customers already run an identity provider

Close enterprise deals faster

Each customer organization connects its own IdP. No custom work per customer.

People land at the right door

Type a work email and you are sent to your company's sign-in, based on a domain proved by DNS.

Access follows the directory

Group rules map to roles at sign-in, and SCIM removes people when they leave.

How it works

Service-provider sign-in, step by step

1PersonType a work emailHome-realm discovery checks the domain. It never reveals whether the person exists.
2Identity StudioSend an AuthnRequestOver HTTP-Redirect to the IdP the customer connected.
3Customer IdPPost a signed ResponseTo the ACS over HTTP-POST. InResponseTo is required, so unsolicited responses are refused.
4Identity StudioVerify and mapSignature checked; email and name read; group rules decide the role.
5Your appPerson signed inWith an organization membership created on first sign-in when auto-provisioning is on.

Standards we implement

What our SAML speaks

Standard	What we support	Status
SAML 2.0 Web SSO · SP	Per-organization connections. IdP metadata is pasted, never fetched. Redirect out, POST in. Assertions must be signed.	Early access
SAML 2.0 · IdP per application	Your app as IdP for registered service providers: up to 10 ACS URLs, signed assertions (RSA-SHA256, exclusive c14n), Redirect and POST in, POST out.	Early access
Encrypted assertions	As IdP: AES-256-CBC with RSA-OAEP when the service provider registers an encryption certificate.	Early access
Single Logout	Inbound signed LogoutRequest in both roles, inside a time window and replay-checked.	Early access
NameID formats	emailAddress, unspecified and persistent (an HMAC per app, service provider and person, never stored).	Early access
Home-realm discovery	Domains proved by a DNS TXT record at _vaarta-domain.<domain>, re-checked daily. Free-mail domains refused; one organization per domain.	Live
OpenID Connect connections	Discovery or explicit endpoints, PKCE S256, nonce, asymmetric algorithms only. Google, Microsoft, GitHub and LinkedIn ready-made.	Live

Not offered today: IdP-initiated sign-in, the Artifact binding, signed AuthnRequests from the service-provider side, decrypting assertions as service provider, logout pushed out to other apps.

Configuration

What admins set

Option	Values	Default
Connection (organization admin)	Display name, IdP metadata XML (256 KiB max), entity ID, allowed email domains, one app or all	active
auto_provision	Create the membership on first sign-in	on
Role mapping	Claim (groups or roles), value, role (owner, admin, billing admin, member, viewer), priority	priority 100
Service provider (app admin)	entity_id, 1 to 10 ACS URLs, name_id_format, attribute release (email, name)	emailAddress
require_signed_requests	Refuse unsigned AuthnRequests from that service provider	off
Assertion lifetime · clock skew	Deployment-wide	300 s · 180 s

Under the hood

What protects it

From the code

services/saml_sp.pythe service-provider metadata

return (
  f'<md:EntityDescriptor xmlns:md="{MD_NS}" entityID="{sp_entity_id}">'
  f'<md:SPSSODescriptor AuthnRequestsSigned="false" '
  f'WantAssertionsSigned="true" '
  f'protocolSupportEnumeration="{SAMLP_NS}">'
  f'{slo}'
  f'<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:'
  f'nameid-format:emailAddress</md:NameIDFormat>'
  f'<md:AssertionConsumerService Binding="{BINDING_POST}" '
  f'Location="{acs_url}" index="0" isDefault="true"/>'
  f'</md:SPSSODescriptor></md:EntityDescriptor>'
)

Security notes

The XML parser refuses DTDs and entities before any signature is read.
Signed assertions are required; SHA-1 signatures are refused on the service-provider side.
Logout requests must be signed, inside a time window, and are checked for replay.
Discovery answers the same way whether or not a person exists.
Tested end to end against Keycloak 26 as identity provider and as service provider.

Works with

Part of one platform

SCIM provisioning Directories add and remove people.Organizations Verified domains and roles.OAuth & OpenID Connect The other half of SSO.Integrations Identity providers we connect to.

Which plans include it, and the limits that apply, are on the plans page.See plans →

Explore the platform

One platform, every piece of sign-in and access

Bring enterprise SSO to your product

Talk to us about early access to SAML for your customers.

Book a demo Start free trial