SAML 2.0 Single Sign-On

Learn how to set up a secure, single sign-on experience for users with SAML 2.0.

Last updated on November 28th, 2023

What is SAML 2.0 Single Sign On?

Security Assertion Markup Language (SAML) is a standard for logging users into applications based on their sessions from another platform. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:

  • No need to type in credentials
  • No need to remember and renew passwords
  • No weak passwords

Most organizations already know the identity of users because they are logged in to their Active Directory domain or intranet. It makes sense to use this information to log users into other applications, including our platform, and one of the more elegant ways of doing this is by using SAML.

How does it work?

SAML SSO allows for the transfer of a user's identity from one location (identity provider) to another (service provider) through a digital exchange of XML documents. The process goes as follows: a user logs into an identity provider and attempts to access a remote application, the application redirects the user back to the identity provider for authentication, after which the identity provider sends a signed XML document containing the user's information to the service provider. The service provider, already familiar with the identity provider, verifies the document with a certificate fingerprint and grants the user access to the app.

SAML Settings in CoreX

To configure SSO in CoreX you will need to

  1. Click on your user profile on the top right
  2. Click Settings
  3. Navigate to the Single Sign-On tab

No Single Sign-On tab?

You must be an Admin user to have access to the tab. If you're an Admin user and still do not see it, contact your success or account manager to have the feature activated for you.



Afterwards, you have to fill the following details.

Mandatory Configuration Parameters

These are to be provided by the Identity Provider (IdP) of your choice and set in Uberall:

  • IdP Entity Id: A unique name for the SAML entity (ex: Azure). This name will be added to the SP Response URL, which needs to be input into the IdP service provider. The name must be alphanumeric and have no spaces.
  • IdP SSO URL: The location where users will be redirected for logging in. This should be the client's platform URL.
  • Certificate: The client should provide the certificate information from their IdP provider, in the form of an alphanumerical string (x.509 certificate).
  • Base URL: This should be unless there's a whitelabel setup, in which case it should be the base URL of the active Whitelabel domain.

Uberall-provided Configuration Parameters

These are to be consumed by the IdP provider:

  • Metadata Endpoint: The application-defined unique identifier that is the intended audience of the SAML assertion.
  • SSO URL or ACS Endpoint: The location where the SAML assertion is sent with a HTTP POST request and where the client's IdP will redirect an authenticated user after successful sign-in.

Creating and updating users via Just-in-time (JIT) provisioning

Uberall allows creating or updating users on the fly. In order to do this, you will need to adjust your IdP settings so that the following attributes are provided in the XML assertion.

Mandatory fields

These are required to identify the user

  • FirstName - user's first name
  • LastName - user's last name
  • Email - user's emails
  • Identifier - a stable and unique user identifier according to the clients internal system

Optional fields

These can ensure the user gets the intended access control and permissions

  • Role  - the Uberall user role. If the role is present, we do not make any role assumptions outlined under “Extra rules” section. 
  • Locations - the Uberall location ids which need to be assigned. Applicable for Users with Role LOCATION_MANAGER.
  • Businesses - the Uberall business ids of the businesses which need to be assigned. Applicable for Users with Role ACCOUNT_MANAGER or BUSINESS_MANAGER.
  • Groups - the Uberall group ids which can be associated with the user.
  • Features - a list of the features which need to be enabled for the user.
  • WLIdentifier - the Uberall whitelabel identifier which needs to be assigned to the user in case of multiple WLs in the SP. We will fallback to the default white labeled ID if none is provided.

Extra rules

These are to be considered and make User creation and automation easier for your workflow.

  • Passing multiple values in Businesses → creates a BUSINSS_MANAGER and assigns the businesses.
  • Passing a single value in Businesses → creates a BUSINESS_MANAGER and assigns the business.
  • Passing Locations OR Groups → create a LOCATION_MANAGER and assigns the location(s) or group(s)



Q: Can we add a redirectUrl after? 

A: Yes the authenticate endpoint supports a redirectUrl param so the end of the flow the user will land on that page. The redirectUrl is fully dynamic it just needs the URL part ex: ?redirectUrl=/dashboard


Was this article helpful?

Save as PDF