Note: This document is targeted at IT Administrators.
For Store and Head office documentation on how to manage SSO users go here:
Logging in and managing Single Sign On (SSO) Users
Single Sign On
Enterprise users can access Qudini with corporate credentials if SAML-based SSO (SSO/SAML integration) is enabled for their account.
Single Sign-On (SSO) is the general term for the various techniques which allow a user to access multiple applications from a single authorization point, which is managed by an identity provider (IDP). Security Assertion Markup Language (SAML 2.0) is a leading industry standard for exchanging the authentication and authorization data that Qudini supports as a service provider (SP).
No actual passwords are transferred to or from Qudini during the authorisation event. Instead, Qudini receives a SAML assertion of the user identity, which is valid for a limited period of time and digitally signed.
Qudini uses an SP (Service Provider) initiated flow. This means users first visit Qudini's login page, and are then directed to your Identity service to login, then automatically redirected back to Qudini.
Administrator Setup
SAML is a premium feature, so please first speak to your account manager if you would like to set up SAML authentication.
Note that the following guide requires a technical understanding of SSO. It is recommended to be read by an IT Administrator.
Once you have access you can manage the setup process by accessing the 'Authentication' section within your Merchant Admin settings. This is only accessible to Merchant Admin users:
| Navigate to 'Authentication' |  |
| Enable 'Single Sign On' for your merchant. |  |
Add Qudini as a SAML application in your Identity Service. You need to ensure your SSO provider supports SAML 2.0. Compatible SSO services includes Azure AD, PingFederate, Google Apps identity service, Okta, Bitium, OneLogin. | |
You will need the following details which can be found further down this article. SP URN / Audience URI / SP Entity ID: This is an identifier you will be required to enter in your SSO providers setup page. e.g: urn:amazon:cognito:sp:xxxxxxxxx ACS (assertion consumer) / Reply URL: Specifies where the application expects to receive the SAML token. The reply URL is also referred to as the Assertion Consumer Service (ACS) URL. e.g https://<domain-prefix>/saml2/idpresponse Once set up, your service provider will give you either a Meta XML Url, or allow you to download a Meta XML file. | Azure AD example: |
| You should then upload or enter the SAML url into this section of our settings and press 'Save'. |  |
| Finally you need to configure an SSO 'Organisation' keyword. This is required for your users to enter on the login page so our system knows which SSO service to direct them to. You can use your company name, or the domain name of your emails. Tip: If you use MDM to deploy our app, you can pre-set this value for users. See our MDM docs here. |  |
Attribute setup
When users login using SSO, Qudini uses 'Just in time' provisioning. This means users don't need to be set up on Qudini first before they can log in. In order for this to work best we require certain attributes to be passed so we know which store the user belongs to.
| Attribute name | Details |
|---|---|
Unique User Identifier | Required : The username of your user. This should be a unique identifier in your system. Recommended to use the email address. |
| emailaddress | Required: The email address of the user |
| name | Required: The full name of the user (used to display their name in Qudini's app) |
| store_id | Optional: The store ID of the user. If present, we will match the user to their store using this ID and the IDs configured in Qudini. Note: This can be left blank for Merchant Admin User (Learn more about Merchant users). |
| employee_id | Optional: The users employee ID. If present we will set this value in the employee ID field of the user. This is useful for performing lookups and finding users later. |
It is possible to configure the actual SAML attributes within our settings page. Qudini will then use the configured attribute names:
Note: We recommend testing this process with a user before asking other users to log in to confirm the attributes are mapped correctly.
SAML Settings:
This table has the relevant values you will need depending on your environment. If you are using a private hosting environment, please use the values from the region you are hosted in.
| Environment | Identifier (Entity ID) | Reply URL (Assertion Consumer Service |
|---|---|---|
| EU (app.qudini.com) | urn:amazon:cognito:sp:eu-west- | https://idp-eu.qudini.com/saml2/idpresponse |
| AUS (au.qudini.com) | urn:amazon:cognito:sp:ap- | https://idp-au.qudini.com/saml2/idpresponse |
| US (us.qudini.com) | urn:amazon:cognito:sp:us-east- | https://idp-us.qudini.com/saml2/idpresponse |
Troubleshooting
Users are created but with the wrong details (name, email):
The attribute mapping may not be correct. Firstly check that your IDP is setup to send the required SAML attributes, and the naming is configured to match what is required.
This article explains how to debug the SAML response and confirm exactly which attributes are being sent: https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml_view-saml-response.html
Future enhancements: We will be adding additional attributes to help map users to specific roles and merchant admin permissions too.