Skip to main content

SSO Configuration

This guide covers SAML 2.0 Single Sign-On (SSO) for Owner users, so they can access Loyal Guru with their corporate identity provider credentials (for example Azure AD / Microsoft Entra ID or Okta).

SSO controls authentication only. It does not replace Users & Roles. For password policy, MFA, and idle timeout, see Security, SSO, and MFA and User Security.

note

This page is about Owner employee SSO (SAML). It is not Signed SSO Redirect (WL App β†’ another client system).

Authentication models​

Regardless of the model chosen for client users, Loyal Guru team members always authenticate via Loyal Guru's own corporate SSO. LG users are never managed through the client's IdP.

Model 1 β€” Full SSO​

All client users access Owner exclusively through SSO. Username and password login is not available for client users.

AdvantagesDisadvantages
Centralised access control from the IdP; corporate security policies (MFA, password rotation) apply globally.Any IdP outage blocks platform access for all users. Every user must be provisioned in the IdP.

When to use: Unified, fully controlled authentication for all platform users (large enterprises, regulated industries, mandatory MFA at IdP).

Model 2 β€” Hybrid (SSO + username & password)​

Client users can access via SSO or via username and password.

AdvantagesDisadvantages
Users not yet in the IdP can still log in; smoother transition; external collaborators outside the directory.Access control is less centralised; non-SSO users may have weaker security.

When to use: Mid-migration to SSO, external agencies/freelancers, or multi-brand setups where some groups are outside the main IdP.

Model 3 β€” Username & password only​

No SSO for client users. Access is managed inside Loyal Guru.

AdvantagesDisadvantages
Simple setup; no IdP configuration.No centralised identity management; separate passwords; manual access revocation.

When to use: No IdP, pilots/POCs, or small stable teams.

Important considerations​

  • Dynamic metadata loading: Loyal Guru loads the IdP metadata file every time SSO runs. Changes on the IdP side are reflected immediately.
  • Client configuration prevails: Settings present in the IdP metadata override Loyal Guru's configuration.

Prerequisites​

  • Administrative access to your IdP (Azure AD / Entra ID, Okta, G Suite, or similar).
  • Administrative access to Loyal Guru (Loyal Guru configures the company side).
  • A publicly accessible IdP metadata URL that successfully downloads the XML metadata file.

Step-by-step configuration​

1. Initial configuration on Loyal Guru​

Loyal Guru performs the initial platform setup. Minimum information:

  1. Enable SAML2 SSO for the company.
  2. Set associated domains β€” only emails from these domains can attempt SSO login.
  3. Set the client's IdP metadata URL β€” must download a valid XML metadata file.
  4. Set expected attributes (for example email, first name, last name). A dummy mapping is acceptable until the IdP is ready.
tip

During initial setup, avoid advanced security settings (signatures, encryption) until the basic connection works. Add hardening afterwards.

2. Configuration in your IdP​

Your team configures the SAML application:

  1. Create a SAML application dedicated to Loyal Guru.

  2. Upload Loyal Guru's SP metadata (endpoints and certificates). Download it from:

    https://management-api.loyal.guru/sso/saml2/{client_name}/metadata

    Replace {client_name} with the client identifier Loyal Guru confirms with you.

  3. Attribute mapping β€” claim names and values must match what Loyal Guru expects (for example email, firstName, lastName). Azure clients: see Azure AD / Microsoft Entra ID below.

  4. Assign users/groups who may access Loyal Guru via SSO.

warning

Do not mix up the two metadata URLs. The URL above (.../sso/saml2/{client_name}/metadata) is Loyal Guru's β€” you upload it into your IdP. After the SAML app is set up, send Loyal Guru your own IdP metadata URL (a different URL from your IdP) so step 1.3 can be completed. Sending back Loyal Guru's metadata URL by mistake is a common error.

Azure AD / Microsoft Entra ID β€” Attributes & Claims​

If your Identity Provider is Azure AD (Microsoft Entra ID), edit Attributes & Claims like this:

  1. Edit the name claim: change the source from user.userprincipalname to user.givenname.
  2. Delete firstName (it would be a duplicate).
  3. Rename lastName to surname_1 (source stays user.surname).
  4. Leave email and Unique User Identifier as they are.

Check:

Claim name (no namespace)Source
nameuser.givenname
surname_1user.surname

3. Testing​

  1. Provide a test user from your directory.
  2. Ensure a user with that email already exists in Loyal Guru β€” SSO does not create the Owner user.
  3. Test login through the SSO flow.

4. Troubleshooting​

  • IdP metadata URL is accessible and valid.
  • Attributes sent by the IdP match what Loyal Guru expects (including Azure claim names above).
  • Test user is assigned to the SAML application.
  • User email pre-exists in Loyal Guru.

5. Hardening​

After the basic connection works, align security settings with your security team. Loyal Guru recommended values:

NameValue
authn_requests_signedtrue
check_idp_cert_expirationtrue
logout_requests_signedtrue
logout_responses_signedtrue
metadata_signedtrue
want_assertions_signedtrue
want_name_idtrue

Re-test request and response flows after changing these settings.