Skip to main content

Single Sign-On

Updated

Administrate supports Single Sign-On (SSO) for:

  • Administrate Core – staff Users logging in to the TMS
  • Administrate LMS – learners logging in to the LMS

Administrate uses OpenID Connect (OIDC), an industry-standard protocol for authentication.

Enabling SSO allows users to authenticate using an external identity provider, reducing the need to manage separate credentials.

Single Sign-On configuration

Use SSO for Administrate Core and/or Administrate LMS

Activating providers

After configuring a provider, you control where it applies:

  • Enabled for Core – allows staff Users to log in to Administrate using SSO
  • Enabled for LMS – allows learners to log in to the LMS using SSO

Update Provider dialog box

Update Provider dialog box

Google SSO

Google SSO is preconfigured in Administrate. To use it:

  • Enable it for Core and/or LMS
  • A Login with Google button will appear on the login page

Login with Google button

Log in to Administrate using Google credentials

On first login, users must grant permissions to Administrate.

First time signing in through Google SSO

First-time Google SSO authorization

If login fails, users are returned to the login screen with the message: No user registered with this email address.

Google SSO error when no matching user exists

Failed login example

Set up Azure SSO

Azure SSO requires configuration in both Azure and Administrate.

Azure setup

  1. Sign in to Azure Portal.
  2. Navigate to Azure Active Directory → App registrations.
  3. Create or select an application.
  4. Add redirect URIs:
    • https://login.getadministrate.com/oauth2
    • https://identity.getadministrate.com/oauth2/finalize
  5. Copy the Application (client) ID.
  6. Create and copy a Client Secret.
  7. Copy the Directory (tenant) ID.
  8. Ensure permissions include Sign in and read user profile.

Administrate setup

  1. Open Control Panel → Login Configuration.
  2. Select Create Configuration → OAuth 2.0.
  3. Complete the fields:
  • Name: Azure SSO
  • Redirect URI: https://login.getadministrate.com/oauth2
  • OAuth2 Client ID: Azure Application ID
  • OAuth2 Client Secret: Azure secret
  • OAuth2 Auth URI: https://login.microsoftonline.com/<DirectoryID>/oauth2/authorize
  • OAuth2 Token URI: https://login.microsoftonline.com/<DirectoryID>/oauth2/token
  • OAuth2 Userinfo URI: https://login.microsoftonline.com/<DirectoryID>/openid/userinfo
  • Scope: openid profile email

Enable the provider for Core and/or LMS, then click Save.

If LMS mapping is required, contact Administrate Support .

Add a different SSO provider

Administrate supports any provider that uses OpenID Connect (OIDC).

Click + Add and enter the provider’s OAuth details.

Add Provider details screen

Add Provider details screen

Hint

Use Lookup issuer (for example, accounts.google.com) to auto-populate OAuth endpoints where supported.

Redirect URI defaults:

  • Core: https://identity.getadministrate.com/oauth2/finalize
  • LMS: https://identity.getadministrate.com/oauth2/finalize

Add a SAML 2.0 provider (TMS only)

Select SAML 2.0 from Create Configuration to configure a SAML provider.

Create SAML configuration

SAML SSO is only available for the TMS (Core).
 

Step 1: Generate your SP metadata in Administrate

Before configuring your identity provider (IdP), generate the Service Provider (SP) metadata from the SAML configuration page in Administrate. This XML file contains everything your IdP needs to trust Administrate as a Service Provider.

A sample metadata file looks like this:

<md:EntityDescriptor entityID="https://identity.getadministrate.com" ...>
 <md:SPSSODescriptor ...>
   <md:KeyDescriptor use="signing">...</md:KeyDescriptor>
   <md:KeyDescriptor use="encryption">...</md:KeyDescriptor>
   <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
   <md:AssertionConsumerService
     Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
     Location="https://identity.getadministrate.com/saml/acs?brand=...&provider=..."
     index="1"/>
 </md:SPSSODescriptor>
</md:EntityDescriptor>
 
Save this file or keep the page open — you'll reference specific values from it in Step 2. 


Step 2: Map metadata values into your identity provider

Each value in the metadata file corresponds to a field in your IdP's SAML app configuration, though the field names vary by provider. Use the table below to find the right field for your IdP.

Value in Administrate's metadata What it is Where to find it in the XML
entityID (root attribute) The unique identifier for Administrate as a Service Provider <md:EntityDescriptor entityID="...">
AssertionConsumerService Location The URL your IdP sends the SAML response to after a successful login <md:AssertionConsumerService ... Location="...">
X509Certificate (signing) The public certificate Administrate uses to verify/sign SAML messages — only needed if your IdP requires an SP certificate upload <md:KeyDescriptor use="signing">
NameIDFormat Confirms Administrate expects the user's email address as the NameID <md:NameIDFormat>

Provider-specific field names
 

Provider Entity ID field ACS URL field
Okta Audience URI (SP Entity ID) Single sign-on URL
Azure AD / Entra ID Identifier (Entity ID) Reply URL (Assertion Consumer Service URL)
OneLogin Audience Recipient / ACS (Consumer) URL
Google Workspace Entity ID ACS URL
PingFederate SP Entity ID / Partner's Entity ID Assertion Consumer Service URL
ADFS Relying Party Identifier Endpoint (SAML Assertion Consumer)

Tip: Regardless of what your IdP calls it, the Entity ID field should always be set to the value of the entityID attribute at the top of the metadata file (https://identity.getadministrate.com by default), and the ACS URL field should be set to the full Location value from AssertionConsumerService — including the brand and provider query parameters. These parameters are unique to your Administrate instance, so don't truncate the URL.

 

Step 3: Complete the SAML configuration in Administrate

 

  • Name — a label for this configuration (e.g. your company name or IdP name)
  • IDP Entity ID — your identity provider's Entity ID (sometimes called the "Issuer URL" or "Identity Provider Issuer" in your IdP's own SSO settings)
  • IDP SSO Redirect URL — your IdP's SAML sign-on URL (sometimes called "Login URL," "SSO URL," or "SAML 2.0 Endpoint")
  • IDP Public Certificate — paste the X.509 signing certificate from your IdP. Depending on the IDP, when viewed in a text editor, the certificate may or may not include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. You can paste the certificate text with or without those lines.
  • Email URN — the SAML attribute name your IdP uses to send the user's email address (this depends on how your IdP maps user attributes — confirm the exact attribute name/URN in your IdP's attribute statement configuration)

Under Service Provider, decide whether you want Administrate to:

  • Signs Authentication Request Message — sign outgoing SAML requests
  • Signs Metadata — sign the SP metadata file

Under Identity Provider, set these to match how your IdP is configured to send responses:

  • Signs Messages
  • Signs Assertions
  • Sends NameID with Response
  • Encrypts NameID
  • Encrypts Assertions

Tip: The checkboxes under Identity Provider must match your IdP's actual behavior, not just be toggled on for "more security." For example, if your IdP doesn't encrypt assertions, leaving Encrypts Assertions checked here will cause login to fail because Administrate will expect an encrypted payload that never arrives. Check your IdP's SAML app settings to confirm which of these are actually enabled before matching them here.

Click Save, then enable the provider for Core as needed (see Activating providers).

Troubleshooting SAML Configuration

If login fails after setup, double check:

  • The Entity ID in your IdP exactly matches the entityID value in Administrate's metadata
  • The ACS URL includes the full brand and provider query parameters
  • The NameID format your IdP sends matches emailAddress, and that the email matches the User record in Administrate

FAQ

I can’t log in through SSO

Ensure the email address in Administrate matches the one provided by your identity provider.

Example: user@company.com vs user@googlemail.com will fail.

Resources

OpenID Connect – official documentation

Related to

Related articles