SSO (SAML / Microsoft Entra) for Go Operator

Problem

You want staff and consumers to sign in to Gladstone with your own Microsoft Entra (Azure AD) accounts via SAML, and need to know when to use it, how sign-in works and how to fix failures.

Resolution

  1. Decide whether SSO is needed

    • SSO is optional and most sites don't use it. It is typically used by organisations whose staff and members already have organisation accounts (for example, a university's staff and students).
    • Only enable SSO if the site uses it. SSO changes how all staff and customer logins sign in, and left on by mistake it forces external users (including Gladstone staff and trainers) through the organisation's login.

  2. Ask Gladstone Support to set it up

  3. Configure the shared and per-customer items

    • One shared Gladstone sign-in service serves every customer, with one Reply URL. Set up the following:
    ItemScopeWhere
    Reply URL (ACS)SharedEntra Enterprise App > Basic SAML Configuration
    Identifier (Entity ID)Shared (one service-wide value)Entra Enterprise App, plus one setting on Gladstone's side
    Enterprise AppPer customerCustomer's own Entra directory
    Federation metadata URLPer customerFrom the customer's Entra; Operator setting Authentication_SamlMetadataUrl
    Staff group IDPer customerAuthentication_SsoStaffGroupId
    Consumer group mappingsPer customerAuthentication.ConsumerSsoIdpGroups
    Operator web addressPer customerRegistered against your environment; RelayState is matched against this

  4. Make sure sign-in starts from Operator

    • Launching from the Entra/My Apps tile sends no RelayState, so Gladstone can't tell which customer the response is for and sign-in fails.
    • Set the tile's Sign-on URL to your Operator address, so the tile opens Operator and Operator starts the sign-in.

  5. Make sure your Operator address is registered

    • A new or changed web address (including a vanity domain) must be registered by Gladstone before SSO will work on it. One that isn't registered against your environment makes both log-in and the callback fail.

  6. Check the sign-in round trip (if troubleshooting)

    • The user clicks Sign in with SSO on your Operator address (for example https://<customer>.gladstonesoftware.co.uk/).
    • Gladstone identifies the customer from that host name, writes it into RelayState, and sends the browser to your Entra.
    • After sign-in, Entra makes the browser post the SAML response to the shared Reply URL (…/log-in-callback), with RelayState unchanged. Entra never calls Gladstone directly, and doesn't interpret RelayState (the SAML standard requires it to be returned unchanged).
    • At the callback, and only there, Gladstone ignores the host name, reads the customer address from RelayState and looks it up among the registered customer addresses. From then on it works entirely in that customer's configuration and data.
    • It checks the response was signed by that customer's Entra (per their metadata), then finds or creates the user (this is where auto-provisioning happens).
    • It redirects back to Operator with a one-time token, and Operator redeems it to create the session.
    • Every step is the user's browser moving from one site to the next; nothing goes directly server to server. Think of a central post room that routes every reply by the address on the reply envelope (RelayState), not the address of the building.

  7. Check the Operator SSO settings if external users are forced to your login

    • If everyone, including external users such as Gladstone staff, is forced through the organisation's login, SSO has probably been switched on by mistake for a site that doesn't use it. Contact Gladstone Support.

Notes

This page as markdown · All pages · llms.txt