SSO Integration

Last updated:

Revspire uses SAML 2.0 single sign-on (SSO) to authenticate pre-provisioned users through your identity provider. Configure and test SSO before enabling an SSO-only policy. Use SCIM separately when you also want automated user and group provisioning.

Supported Providers

  1. Okta
  2. OneLogin
  3. Microsoft Entra ID
  4. Custom SAML 2.0

Before You Start

  • The Revspire organization must have an active Revspire Deal Room entitlement.
  • Use View SSO Settings , View SAML SP Certificate , and the relevant Create SSO Providers or Edit SSO Providers permissions. Enabling an SSO-only policy also requires Manage SSO Enforcement .
  • Create each test user in Revspire first, or provision the user through SCIM. SAML login does not create users just in time.
  • Make sure each test account has an active license and a unique Revspire username or email.
  • Keep an audited recovery administrator available until optional SSO has been tested with multiple users.

Step 1: Copy the Revspire Service Provider Values

Open Revspire > Setup > SSO . The endpoint panel provides copy controls for these tenant-specific values:

ACS URL = <copy the Revspire ACS URL>
SP Entity ID = <copy the Revspire SP Entity ID>
SP Signing Certificate = <download or copy the Revspire public certificate>
SP Cert SHA256 Fingerprint = <copy for independent verification>

The SP Entity ID is also the Revspire SAML metadata URL. The ACS binding is HTTP-POST.

Do not register the displayed SP Login URL as a generic IdP start URL: Revspire calls it only after resolving the user and tenant. Do not register SP Logout URL as an inbound SAML callback: it is Revspire’s authenticated application logout endpoint, and Revspire metadata does not advertise a SAML SingleLogoutService.

Step 2: Apply the Required SAML Trust Settings

Protocol = SAML 2.0
ACS binding = HTTP-POST
Audience / SP Entity ID = exact Revspire SP Entity ID
SAML Response signature = required
SAML Assertion signature = required
Signature algorithm = RSA-SHA256
Digest algorithm = SHA-256
Assertion encryption = disabled
Authentication flow = SP-initiated

Revspire signs authentication requests. Where your identity provider supports signed-request verification, trust the Revspire SP signing certificate. Leave a configured default RelayState blank and preserve the opaque RelayState sent with each Revspire request. Revspire rejects an unsigned response, an unsigned assertion, multiple assertions, a wrong audience, or an encrypted assertion.

Step 3: Configure a Stable Identity and Bootstrap Claim

Use a stable, non-empty, non-reassigned value as the SAML NameID . On the first successful login, Revspire also needs one supported claim that uniquely matches an existing active Revspire user:

Recommended username claim name = revspire_username
Recommended username claim value = exact Revspire username

Recommended email claim name = email
Recommended email claim value = exact Revspire email

NameID = immutable identity-provider user identifier
NameID format = Unspecified or Persistent

Revspire accepts common username claims such as username , preferred_username , and upn , and common email claims such as email and mail . The first match must resolve to exactly one user. Duplicate or conflicting matches fail closed. After the first successful match, Revspire binds that provider’s NameID to the user; changing email does not change the binding. SAML claims are lookup hints, not user synchronization: manage later attribute and lifecycle changes in Revspire or through SCIM.

Step 4: Copy the Identity Provider Values

Issuer Entity ID = <exact IdP issuer>
SSO URL (IdP Login URL) = <HTTPS SAML SSO endpoint>
IdP SLO URL (Optional) = <HTTPS IdP logout endpoint, if supplied>
X.509 Certificate = <currently valid IdP signing certificate in PEM format>

The issuer is immutable after the provider is created. If the issuer changes, create and test a new provider.

Step 5: Add and Test the Provider

  1. In Revspire > Setup > SSO , click Add and select the provider type.
  2. Paste the exact issuer, HTTPS SSO URL, optional IdP SLO URL, and currently valid IdP signing certificate.
  3. Save the provider and assign one pre-provisioned test user in the identity provider. The first provider becomes primary automatically. If the organization has multiple providers, use a controlled test window and Make Primary ; only the primary provider handles normal Revspire-initiated login.
  4. Start at the normal Revspire login page, enter or select the account, and choose Sign In with SSO . Do not test from an IdP tile unless your Revspire deployment has explicitly enabled IdP-initiated SAML.
  5. Test multiple users, logout, error recovery, and a second browser before enabling SSO-only login. Keep IdP and Revspire server clocks synchronized and complete the flow promptly.

Certificate Rollover

  1. Select the provider and open its provider and certificate settings.
  2. Add the replacement IdP signing certificate before the identity provider starts using it.
  3. Confirm its validity window and SHA-256 fingerprint.
  4. After the identity provider has switched and login succeeds, deactivate the old certificate.

Revspire will not let you deactivate the last certificate that is currently valid. You may preload a future certificate while a current certificate remains usable. Never delete and recreate the provider merely to rotate an IdP signing certificate. The downloadable Revspire SP certificate is separate; coordinate any SP certificate change with Revspire.

SSO Policy Modes

  • Optional SSO: test the provider before enforcing it organization-wide. Local login may remain available to unbound local users, but once an account is SAML-bound, that account must continue using federated login even while the organization policy is optional.
  • SSO-only: internal employees must use the primary SAML provider. Password and social login, password reset/change, and local identity-change flows are blocked. Enabling this policy revokes affected employee sessions and active password-reset links. External partner users are exempt from the organization-wide enforcement policy.
  • Turning off SSO-only does not convert a SAML-bound or SCIM-managed account back to local authentication.
  • Keep any break-glass account narrowly scoped, separately protected, monitored, and documented.

SCIM Provisioning

SSO authenticates users; SCIM provisions and deactivates users and groups. Configure the provider-scoped SCIM connection only after SAML login works. Generating or rotating its bearer token requires Generate API Tokens .

Continue with the SCIM Provisioning overview.

In this section