Skip to content
// Glossary · Governance

SSO and SAML

Also called: single sign-on, SAML 2.0, federated authentication

What are SSO and SAML?

Single sign-on lets people reach an application using an account held by their organization identity provider. SAML is a standard for the exchange that makes that work: the provider asserts who somebody is, and the application trusts that assertion rather than holding a password.

// In more depth

What it changes operationally.

The security benefit is real but secondary. The main change is who controls access.

01

Credentials stop being per application

Nobody sets a password for your product, because there is no password to set. Authentication is delegated to the provider the organization already runs, so the credential lives in one place.

02

Offboarding becomes reliable

Disabling somebody in the directory ends their access everywhere it is federated. Without SSO, offboarding depends on somebody remembering every application, which is the step that gets missed.

03

Policy is inherited

Multi-factor requirements, device rules, conditional access: all enforced by the provider and applied to your application without you implementing any of it.

// Why it matters

Why organizations insist on it.

It is usually a procurement requirement before it is a security preference.

One credential to govern

Password policy, rotation, and MFA are enforced once at the provider rather than negotiated per application.

Leaving actually works

Directory-driven access is what makes offboarding a single action instead of a checklist.

Auditors ask for it

Centralised authentication is a control that is easy to evidence, which is why it appears in most security reviews.

// Commonly confused with

Commonly confused with.

Three things in the same area.

SCIMSAML handles authentication: proving who somebody is at sign-in. SCIM handles provisioning: creating and deactivating the account in the first place. Most organizations want both.
OAuthOAuth is about delegated authorisation, granting an application limited access to a resource. Overlapping ecosystem, different job from federated sign-in.
RBACSSO decides whether you get in. RBAC decides what you can do once you are in. Independent questions.
// FAQ

SSO and SAML questions

What are SSO and SAML?

Single sign-on lets people reach an application with an account held by their organization identity provider. SAML is the standard for the exchange: the provider asserts who somebody is and the application trusts that assertion.

How is SAML different from SCIM?

SAML is authentication, proving identity at sign-in. SCIM is provisioning, creating and deactivating accounts. Most organizations want both, because one governs entry and the other governs existence.

Does Virex support SSO?

Yes. SSO and SAML are part of the platform governance set, alongside SCIM, RBAC, audit logging, and retention policy.

Does it replace role management?

No. SSO decides whether somebody gets in. Roles decide what they can do once inside, which is RBAC and a separate question.

Is Virex SOC 2 certified?

No. Security controls are designed to a SOC 2-oriented control set, and no audit has been completed. We will not claim certification we do not hold.

Authentication your directory controls.

SSO, SCIM, RBAC, and audit logging are part of the platform.