What is SAML?

Security Assertion Markup Language (SAML) is an open, XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider. It lets a user authenticate once and then access multiple applications without re-entering credentials – the mechanism behind most enterprise web-based single sign-on.

Key takeaways

• SAML exchanges signed XML assertions between an identity provider and service providers.
• It enables single sign-on: authenticate once, access many applications.
• Okta, Microsoft Entra ID, ADFS, and OneLogin are common identity providers.
• A Versa SSE Gateway acts as the service provider, identified by an SP entity ID.
• SAML can be layered with device or user certificates for stronger assurance.

On this page: Why it matters · How it works · Types · SAML & Versa · FAQ

Why is SAML important?

Before federated identity standards existed, every application kept its own password store, forcing users to authenticate separately to each one. SAML solved this by letting one trusted identity provider vouch for a user’s identity to any number of service providers, so one login reaches Salesforce, Microsoft 365, Slack, or a private application gateway without a second prompt.

That single point of authentication is also a single point of control. Disabling a user at the identity provider – when someone leaves the company or a credential is compromised – revokes their access everywhere at once, instead of an administrator chasing down every application. Because SAML is open and vendor-neutral, enterprises can pick IdPs and SPs independently and trust that they interoperate – why SAML remains the default for enterprise web SSO.

What is SAML?

A SAML exchange involves two roles. The identity provider (IdP) – Okta, Microsoft Entra ID, ADFS, or Ping Identity – authenticates the user, typically with a password and multi-factor step, and holds the authoritative record of who they are. The service provider (SP) is the application or gateway the user wants to reach; it trusts assertions issued by the IdP rather than authenticating the user itself.

When a user tries to reach a protected resource, the SP redirects them to the IdP. After authenticating the user, the IdP returns a SAML assertion: a signed XML document stating the user’s identity (the NameID) and attributes such as email, role, or group membership. The SP validates the signature and, if it checks out, establishes a session and applies the matching access policy.

Types of SAML

Two initiation patterns exist. SP-initiated SSO starts when the user tries to reach the service provider; the SP redirects them to the IdP, which authenticates them and posts the assertion back. IdP-initiated SSO starts from the identity provider’s application portal – the user picks the app, and the assertion is pushed to the SP without an initial redirect.

The exchange also relies on a few standing components: the SP entity ID (a URI identifying the service provider), the assertion consumer service (ACS) URL (where the IdP posts the assertion), and attribute statements (role, organization, and group claims used for authorization). Group attribute statements let an SP import group membership from the IdP, so policies target IdP groups rather than a separate user list.

SAML & Versa

A Versa SSE Gateway acts as the SAML service provider. Administrators create a SAML authentication profile under Configure > Security Service Edge > User and Device Authentication > Profiles, selecting a preset for the identity provider – Okta, Microsoft Entra ID, or a generic SAML IdP – and supplying the Single Sign-On URL, the SP and IdP entity IDs, and the IdP’s signing certificate, values the IdP portal displays at setup, as covered in Configuring Authentication Profiles on the SSE Gateway. The profile can be scoped to individual users or IdP groups, letting a Secure Access rule enforce policy – such as Internet Protection or Private App Protection – by group membership in the assertion.

Once published and applied to a Secure Access Client rule, the gateway redirects logins to the configured IdP, validates the returned assertion, and establishes the session on success. Events are logged in Concerto under View > Dashboard > Secure Access > Logs > Authentication > Events, and SAML can be layered with certificate authentication for Zero Trust–style verification, per the step-by-step configuration guide.

Frequently asked questions

What is the difference between SAML and LDAP authentication?

LDAP has the Versa gateway query a directory server directly for credentials and group attributes. SAML instead redirects the user to an external identity provider, which authenticates them and returns a signed assertion.

What is a SAML assertion?

A signed XML document the identity provider issues after authenticating a user. It states the user’s identity (NameID) and can carry attributes, such as role or group membership, that the service provider uses for access policy.

Can SAML be combined with certificate-based authentication?

Yes. A Versa SSE Gateway can require device or user certificate validation before or alongside SAML login, so both the endpoint and the user identity are verified – common in regulated and Zero Trust environments.

What is the difference between SP-initiated and IdP-initiated SSO?

SP-initiated SSO begins when a user tries to reach the service provider, which redirects them to authenticate. IdP-initiated SSO begins at the identity provider’s app portal, where the user picks the application and the assertion is pushed to the SP directly.

Which identity providers work with Versa’s SAML implementation?

Versa SSE Gateways support Okta, Microsoft Entra ID, and other standards-compliant SAML 2.0 identity providers, through dedicated presets or a generic profile accepting any IdP’s entity ID, SSO URL, and certificate.

More on SAML

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about SAML, these are worth looking at next.