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
- Click on your user profile on the top right
- Click Settings
- 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 https://uberall.com 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.
Activating SSO for users
Once you have set up the SSO details, you need to activate it for Users and they will be able to login with SSO. To do that go to a User's profile (settings) and activate the Single Sign-on feature
Going forward, that User will be able to log in with SSO through the login page:
Using a password to log in
Even if the SSO feature is activated for a User, they will still be able to use their old passwords to log in. If you wish to enforce more governance and mandate only login with SSO, check the “Enforce SSO” section below.
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 BUSINESS_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)
Enforce SSO
If you want complete control over setting user details and permissions, and want users only with Single Sign-On (SSO) to access the app, you can enable the 'Enforce SSO' feature. You can locate this option within the SSO setup section.
If you want to take advantage of this, you must ensure that all necessary data (user details, user features, user location/business ownership) are passed in the SAML assertions (via the just-in-time provisioning). Once activated, any User changes done outside the SAML provisioning will be rejected – Users cannot be updated via the user interface or API.
FAQs
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