Skip to main content

Single Sign-On Setup (Web) - User Guide

Admins can now connect an identity provider and turn on Single Sign-On for their tenant directly from a self-service setup wizard, without engineering's help.

Written by Trevor Shaffer

Overview

Admins can now set up Single Sign-On (SSO) for their tenant directly from Redlist, without needing engineering's help. A new Single Sign-On tab in the admin user settings walks you through connecting your identity provider (Microsoft Entra ID, Okta, or a generic SAML 2.0 provider), testing the connection safely before anyone is affected, and turning SSO on for your team. Most setups take about 15 minutes.

Accessing Single Sign-On Setup

The Single Sign-On tab appears in admin user settings, after the Permissions tab.

  1. From the navigation, go to your admin user settings (classic Admin > Users, or Settings > Users in Lubrication Management)

  2. Click the Single Sign-On tab

NOTE: You'll need an admin-level role to see and use this tab.

How to Set Up SSO for the First Time

When SSO hasn't been configured yet, the tab shows a Not configured status and a 5-step setup wizard: Get your Redlist SSO details, Configure your identity provider, Upload your metadata XML, Test the connection, and Turn on single sign-on. Each step unlocks once the one before it is complete.

Step 1: Get your Redlist SSO details

This step is expanded by default.

  1. Copy the Domain ID, Identifier (Entity ID), Reply URLs (Assertion Consumer Service), and Sign on URL using the copy button next to each field

  2. Enter these values into your identity provider in Step 2

NOTE: The Reply URLs copy button copies all reply URLs at once, separated by line breaks.

Step 2: Configure your identity provider

  1. Select your provider from the segmented control: Microsoft Entra ID, Okta, or Generic SAML 2.0

  2. Follow the on-screen instructions for your provider, using the details you copied in Step 1

Step 3: Upload your metadata XML

  1. Upload the Federation Metadata XML file your identity provider generates for the Redlist application

  2. Redlist validates the file automatically — a valid file shows a green Metadata valid card with the issuer, upload date, and certificate expiration date

  3. An invalid or expired file shows a red error card explaining the specific problem, with an Upload new file option

NOTE: Only .xml metadata files up to 5 MB are accepted.

Step 4: Test the connection

This step becomes available once metadata is uploaded.

  1. Start the test — this opens your identity provider in a new tab for a real sign-in attempt

  2. A live checklist tracks progress: metadata loaded, redirect to your provider, signature verification, and user match

NOTE: The test uses no session and doesn't change anything for the test user — but the email you test with must already belong to an existing Redlist user in your tenant. If the test fails, the checklist shows exactly which step failed and why. You can cancel and retry, and a downloadable response file is available for failed tests to help with troubleshooting.

Step 5: Turn on single sign-on

This step becomes available once a test succeeds.

  1. Choose who SSO applies to: Current and future users, Future users only, or Current users only

  2. Choose whether individual users can be exempted from SSO (see below)

  3. Click Turn on single sign-on

Managing SSO After It's Turned On

Once SSO is active, the tab shows a management view instead of the setup wizard, with an Active status.

  • Connection card — identity provider, issuer, Domain ID, certificate expiration, and the uploaded metadata file, with a Replace link

  • Who signs in with SSO card — rollout summary and whether individual exemptions are allowed, with Change links to edit either

  • Re-run test — runs the same sandboxed test as setup, without affecting live sign-in

  • Replace metadata — upload new metadata; it must pass a test before it takes effect, so nobody is locked out during the change

  • Disable single sign-on — with a confirmation step

NOTE: If your tenant's SSO was configured before this self-service page existed, some connection details may show as "—" until you replace the metadata file.

Allowing Individual User Exemptions

The "Allow individual users to be exempted from SSO" toggle controls whether admins can let specific users sign in with a password instead of SSO.

  • On — admins can exempt individual users on their user page; exempted users sign in with a password

  • Off — no exemptions; everyone set up for SSO must sign in through your identity provider

NOTE: This is the same underlying setting shown on Company > Security as "Require SSO" — the two screens describe it from opposite directions. Turning exemptions off here is the same as turning "Require SSO" on there.

Disabling SSO

  1. On the management view, click Disable single sign-on

  2. Confirm in the dialog

Disabling reverts everyone in your tenant to password sign-in, but your configuration is kept — you can turn SSO back on later without redoing setup.

Use Cases / Examples

Use Case 1: Connecting Microsoft Entra ID without opening a support ticket

An IT admin copies the Domain ID and Reply URLs from Step 1, sets up the enterprise application in Entra ID, uploads the resulting metadata XML, and runs a test sign-in with their own account — all without contacting Redlist support.

Use Case 2: Rolling out SSO gradually

An admin turns on SSO for future users only, so existing accounts keep signing in with passwords while new hires are provisioned through the identity provider from day one.

Use Case 3: Replacing an expiring certificate

An admin notices the certificate expiration date on the connection card is approaching, uploads new metadata from their identity provider ahead of time, and runs a test — the new metadata isn't live until the test passes, so current SSO users are unaffected during the swap.

Best Practices

  1. Test with an account you control: The test sign-in requires an email address that already matches an existing Redlist user in your tenant — use your own account to avoid delays.

  2. Don't wait for certificates to expire: Replace metadata before the certificate expiration date shown on the connection card to avoid a sign-in disruption.

  3. Start with future users if you're unsure: Rolling out to future users only limits the blast radius while you confirm the setup works as expected.

  4. Keep exemptions on during rollout: Allowing individual exemptions gives you an escape hatch for any user who has trouble with the new identity provider while you validate the connection.

Troubleshooting

Issue: Test connection fails with a user-not-found type error

Solution:

  1. The email address used for the test must already belong to an existing user in your Redlist tenant

  2. Confirm the test account exists in Redlist, then retry the test

Issue: Test connection fails partway through and won't finish

Solution:

  1. Check the live checklist to see which step failed

  2. Cancel and retry, or download the response file from the failed test for troubleshooting with your identity provider admin

Issue: "Require SSO" and the exemptions toggle seem to disagree

Solution:

  1. These are the same setting, shown from opposite directions on Company > Security vs. the Single Sign-On tab

  2. Allowing exemptions here is equivalent to leaving "Require SSO" off there, and vice versa

Issue: Connection details show "—" instead of real values

Solution:

  1. This tenant's SSO was configured before self-service setup existed

  2. Replace the metadata file from the management view to populate the missing details

Summary

The Single Sign-On tab in admin user settings lets admins connect an identity provider, upload and validate metadata, safely test the connection, and turn SSO on for current and/or future users — all without engineering involvement. Once active, the same tab becomes a management view for reviewing the connection, replacing metadata, re-testing, and disabling SSO without losing the configuration.

Related Articles
Did this answer your question?