Skip to content
VIREX
Log inGet started
PlatformAdmin25 min

Set up SSO for your organization

Move authentication to the identity provider you already run, so access to Virex follows the same joiner and leaver process as everything else. The risky part is the cutover, so most of this guide is about not locking anybody out.

// Before you start

What you need first.

This one genuinely requires preparation, unlike most setup tasks.

  • An administrative role in your Virex organization. SSO configuration is an administrative action.
  • Administrative access to your identity provider, or somebody on the call who has it.
  • A test member account you can sign in as, separate from the admin doing the configuration.
  • A decision about scope: SSO covers authentication, and seats still govern product access. They are separate.
// Steps

Six steps

Steps four and five are the ones that matter. Verifying before enforcing is what separates a quiet rollout from an incident.

  1. 01

    Confirm your admin access

    Check you hold an administrative role in the organization before starting, rather than discovering it halfway through a configuration exchange.

    Check: You can reach organization settings and see the identity configuration.

  2. 02

    Decide what SSO covers

    SSO governs how people authenticate. It does not grant product access, which is what seats do, and it does not remove people, which is what SCIM does. Being clear on this now avoids the assumption that turning on SSO handled offboarding.

    Check: You can state which of authentication, product access, and deprovisioning you are solving today.

  3. 03

    Configure the connection

    Exchange the required configuration between your identity provider and Virex. The precise fields differ by provider, so follow the provider-specific detail in the docs rather than a generic description.

    Check: The connection saves without validation errors on either side.

  4. 04

    Verify with one test member

    Sign in as the test member through the identity provider, in a fresh browser session. Do not use the admin account that configured it, because that account may have a session that masks a broken flow.

    Check: The test member reaches the product portal through your identity provider, in a browser with no existing Virex session.

  5. 05

    Enforce organization-wide

    Once verified, require SSO for the organization. Keep an admin able to sign in until you have confirmed several real members are through, so a misconfiguration is recoverable rather than terminal.

    Check: Existing members sign in through the identity provider, and nobody is stuck at the login screen.

  6. 06

    Decide about SCIM

    SSO means a disabled directory account cannot authenticate. It does not remove their seat or their organization membership. If you want that automatic, SCIM provisioning is the next step.

    Check: You have decided whether offboarding is handled by SCIM or by an admin removing seats manually.

// If it does not work

What usually goes wrong.

Almost all of it is scope confusion rather than configuration.

Test member cannot sign inCheck they exist in both the identity provider and the organization, and that you are testing in a browser with no existing Virex session.
Signed in but everything is lockedThat is the expected result of authentication without a seat. SSO got them in; a seat is what grants product access.
A leaver can still sign inSSO alone does not deprovision. Either the directory account is still active, or you need SCIM to propagate the removal.
Admin locked out mid-rolloutThis is why step five keeps an admin path available. Contact us if it happens and we will help you recover access.
Some members bypass SSOEnforcement is organization-wide once enabled. If somebody is still using another route, confirm the enforcement setting actually saved.
// FAQ

Questions about this guide

Which identity providers are supported?

SSO and SAML federation are available for organizations standardising on their own identity provider. Provider-specific configuration lives in the docs, since the exact fields differ per provider.

Will this lock existing members out?

Not if you plan the cutover. Verify with a test member before enforcing organization-wide, and keep an admin able to sign in until you have confirmed the flow end to end.

Does SSO change how seats work?

No. SSO governs authentication, and seats govern product access. A member who signs in through your identity provider still needs a seat for each product they use.

Do we need SCIM as well?

They solve different problems. SSO handles authentication, SCIM handles provisioning and deprovisioning. SCIM is what makes offboarding automatic rather than a manual step.

Is SSO an enterprise-tier upgrade?

No. There are no tiers within a product, so security controls are not held back behind a pricing ladder.

Bring the hard questions.

If your rollout has a constraint this guide does not cover, ask us directly rather than guessing.

Get startedSee pricing