Workspaces, sources, destinations.

A workspace is the tenant. It holds members, the plan, and every connection your team owns. You can belong to many workspaces at once. The sidebar switcher toggles between them, and each keeps its own settings and billing.

A workspace must always retain at least one admin. Demoting or removing the last admin is rejected; promote another member first. When the last membership in a workspace is destroyed, the workspace is destroyed with it.

A source is one inbound SAML connection: one identity provider, one configuration. Each source has its own SP entity ID, ACS URL, SLO URL, and metadata document, all served from the source's token-scoped endpoints on sso.simplesaml.com .

Sources start unconfigured. They become routable, meaning their SAML endpoints accept traffic, once four fields are populated: IdP entity ID, IdP sign-in URL, IdP signing certificate, and a linked destination. The dashboard shows a checklist at the top of every source page until all four are green.

A destination is the URL where Simple SAML delivers the JWT after a successful sign-in. It is two fields: a name and a callback URL.

A destination can serve any number of sources. That makes it natural to point many client IdPs at a single application: each client gets its own source, all sources hand off to the same destination, and your application reads the src claim on the JWT to tell the client connections apart.

A member is a user attached to a workspace with a role of either admin or member . Admins can edit anything and manage the team; members can edit sources, destinations, and tags but can't change the plan or invite people.

Add teammates from Members → Invites . Simple SAML emails a tokenized accept link to the address; on accept, the recipient either signs into an existing account or sets a password for a new one.

A tag is a colored label for organizing sources and destinations inside a workspace. Tags are purely organizational. They don't affect routing. They exist to help you filter the dashboard once you have more connections than fit on a single screen.

Following the data model end-to-end:

1. User hits a sign-in button in your application.
2. Your application redirects them to the source's SP-initiated sign-in URL on sso.simplesaml.com .
3. Simple SAML redirects to the IdP with a signed AuthnRequest.
4. User authenticates on the IdP's screen.
5. IdP posts a SAML response back to Simple SAML's ACS endpoint for that source.
6. Simple SAML validates the signature, expiry, audience, and replay state, then mints an RS256 JWT with a five-minute TTL.
7. Simple SAML auto-POSTs an HTML form to the destination's callback URL with the JWT in a single token field.
8. Your application verifies the JWT against the published JWKS and creates a session.

Simple SAML doesn't persist the SAML assertion itself. Only the response ID, briefly, for replay protection.