SSO Configuration for Azure AD

This article outlines an example configuration for SSO on Azure AD. Each retailer will have to configure their own instance and can choose to make changes to the final configuration. Salesfloor does not guarantee that SSO will function as expected if the retailer chooses to make changes to the configurations contrary to Salesfloor’s instructions.

Skip to:

• Step 1 - Creating an application
• Step 2 - Provide Endpoints and IDs to Salesfloor
• Step 3 - Update the Application Settings
• Step 4 - 

Log into your Azure portal (https://portal.azure.com) to see your dashboard. Locate the menu entries for the “App registrations” and “Enterprise Applications” sections used in this document.

Open dashboard.jpg

Retailers should configure one SSO App for production as well as one SSO App for non-production testing purposes. Follow the steps below to configure an SSO App, and repeat the steps to configure another one. Where necessary, the instructions will point out the configurations that differ between both applications.

Step 1 - Creating an application

Navigate to “App registrations” from the menu. Then click on “New registration”.

Open app_registrations.jpg

Once in the “Register an application” window, fill out the form.

• “Name”: Required - Use a meaningful title such as “Salesfloor SSO - (Non-)Production”.
  For the purpose of these instructions, the new application will be referred to as “Your App”.
• “Supported account types”: Required - Choose the scope of Users who can use the Salesfloor SSO solution to login.
• “Redirect URI”: Optional - Will be defined at a later stage in the instructions.

Open app_registrations_2.jpg

Step 2 - Provide Endpoints and IDs to Salesfloor

Certain fields and value from your Azure AD interface will need to be gathered and transmitted to Salesfloor.

From the “App registrations” page click on “Endpoints”.
Please copy all the URLs and values seen on the right hand side.

Open endpoints.jpg

Click into the SSO App that you created in Step 1.
Please copy the “Application (client) ID” and “Directory (tenant) ID” highlighted in the picture below.

Open application.jpg

Important: Gather all the fields described above, as well as the Client secret mentioned in Step 3.3 below, in a document and properly label each field. Then send the document securely to Salesfloor.

Step 3 - Update the Application Settings

In this step, you will be updating the settings of the application that you created in Step 1. Please click into the Application. Follow the instructions below to manage different setting groups that can be found on the left-hand menu.

You can choose to update the branding section to fit your corporate branding as well as to provide legal disclaimers to your users.

Open application_branding.jpg

 

3.2 - Your App > Authentication

Please Note: This section contains differing instructions for the setup of the Production vs the Non-Production SSO Applications. The screenshot provided is that of the configurations for a Non-Production application.

Production Application

Warning:

• Your URL may not be exactly like in this example. Please confirm with AD beforehand, if needed.
• Your “yourbrand” section should have been shared to you. If needed, contact your AD before.
• Click “Add a platform” to add a “Web” section.
  Click “Add URI” to add the following URI(s). You will need to replace stores.yourdomain.com with your production Salesfloor domain.
• https://stores.yourdomain.com/oauth/code
  
  
• Click “Add a platform” to add a “Mobile and desktop applications” section.
  Click “Add URI” to add the following URI(s).
• salesfloor://oauth/code
• Click “Add a platform” to add a “Single page application” section.
  Click “Add URI” to add the following URI(s).
• https://stores.yourdomain.com/app

Non-Production Application

• Click “Add a platform” to add a “Web” section.
  Click “Add URI” to add the following URI(s). You will need to replace yourbrand with your retailer identifier that will be provided by Salesfloor
  • https://yourbrand.dev.salesfloor.net/oauth/code
  • https://yourbrand-stg.salesfloor.net/oauth/code
  • https://yourbrand-qa04.salesfloor.net/oauth/code
  • https://yourbrand-qa05.salesfloor.net/oauth/code
  • https://yourbrand-qa06.salesfloor.net/oauth/code
    
    
• Click “Add a platform” to add a “Mobile and desktop applications” section.
  Click “Add URI” to add the following URI(s).
  • salesfloor://oauth/code
    
    
• Click “Add a platform” to add a “Single page application” section.
  Click “Add URI” to add the following URI(s).
  • http://localhost:9000/
  • https://yourbrand.dev.salesfloor.net/app
  • https://yourbrand-stg.salesfloor.net/app
  • https://yourbrand-qa04.salesfloor.net/app
  • https://yourbrand-qa05.salesfloor.net/app
  • https://yourbrand-qa06.salesfloor.net/app

Completing the Authentication section for both Production and Non-Production

After filling out the platform sections described above, scroll down to the bottom of the Authentication section. This section is not visible in the screenshot below. Here you will see information and options related to:

• “Hybrid flows”
• “Implicit grant”
• “Public client flows”
• “SLO” aka “Front-channel logout URL”

Salesfloor does not support these features, and they should remain deactivated.

Open application_authentication_stg.jpg

3.3 - Your App > secrets

Salesfloor supports “Client secrets”, also known as an “Application password” to prove its identity during SSO requests.

3.3.1 - Setting up a Client Secret

You will need to create a value (password), and share it with Salesfloor.

Please Note:

• Any Client secret value (password) rotations will need to be coordinated with Salesfloor to avoid jeopardizing the usability of Salesfloor’s application for your users.
• When one secret is going to expire, the retailer could create another secret in advance and send it to Salesfoor since Azure supports multiple secrets Why are there multiple client secrets for each azure client id?

Click “New client secret” to create a secure password.
The “Value” of this secret must be shared securely with Salesfloor in the document described in Step 2.

Open application_secrets.jpg

 

3.4 - Your App > Token configuration

Tokens are used to share additional information from your corporate AD to Salesfloor during the authentication process. Salesfloor requires the user’s “email” to be transmitted as part of the “id_token”. This acts as a unique identifier for the user that is understood by both parties.

Click “Add optional claim”

Please Note: The following screenshot shows the end result once “email” is added as an Optional Claim.

Open application_token_1.jpg

From the “Add optional claim” interface, select the following options:

• “Token Type” - “ID”
• “Claim” - “email” or “UPN”

Open application_token_2.jpg

Select the checkbox to enable the “Turn on the Microsoft Graph email permission (required for claims to appear in token)” option in the final modal to complete the process of adding a “email” as an “Optional Claim”.

Open application_token_3.jpg

 

3.5 - Your App > API permissions

The following API Permissions are needed to allow Salesfloor’s SSO solution to function properly.

Click “Add a permission” on the Configured permissions screen. For each section below please select the values associated

• List of APIs - Select “Microsoft Graph”
• “What type of permission does your application require?” - Select “Delegated permissions”
• “OpenId permissions” - Select “email” & “openid”

Open application_api_1.jpg

Once setup, the “Configured permissions” section will resemble:

Open application_api_2.jpg

 

Step 4 - Enterprise Applications > Assign users and groups & Conditional Access

You must now select users and groups to have access to the new SSO Application. This can be done directly from the “Enterprise applications” section in the menu, by clicking on “1. Assign users and groups”.

You can also set a custom access policy by clicking on “3. Conditional Access” to further restrict access to the SSO Application.

Open enterprise_application.jpg