Frontline Portal - SSO
Updated
by
Leigh Hutchens
Frontline Portal employs current protocols for SSO and user provisioning and maximizes the ongoing support for modern enterprise systems. This helps users adopt best practices while managing and maintaining security policies across their full and part-time employee user base.
At the moment, SSO configuration in Frontline Portal is not self-serve. Customers provide the Frontline Portal team with the necessary information so they can do the configuration. In the future, the SSO solution will be consolidated into the Quinyx platform, in other words, if a customer has SSO, it will be set up in Quinyx and not the old Frontline Portal platform. Read more about Quinyx and SSO here.
SSO (Single Sign-On)
SSO allows your staff to have automatic access to Frontline Portal after having signed into their corporate account. This streamlines the access process and reduces the need for employees to remember and manage another set of login credentials.
For web users of supported browsers, once provisioned, the flow is as shown in the image below. The process, from entering the URL to logging in is fully automated; the only potential user interruption required is if the user needs to sign into their corporate account (in case they aren’t already).
Important points in relation to the basic flow
Please consider the following important points related to the basic flow above:
- While SSO enables this new user flow path, it does so in addition to the existing email/password authentication method.
- A user will only be successfully logged in if they have a properly provisioned account with a name, email address, and a valid Frontline Portal user group.
- Attempts to log in without a properly provisioned account will result in a message: “We are sorry, but we are not able to log you into Frontline Portal, as we are missing some key data or your account is not active. Please contact your System Admin.”
- If a user isn’t signed into their corporate account before the start of the flow, they will be redirected to their corporate login page. The tenant account will need to configure a callback URL if they wish the user to be automatically sent to Frontline Portal after they successfully log in at this point (indicated by the dashed line in the diagram above)
- For security reasons, if the user has been deleted or archived within your IdP, they will not be able to access Frontline Portal.
User Access via mobile app (SSO)
For users of the Frontline Portal mobile app, the user is more likely to have to log in to their corporate account due to how sessions are managed on these devices.
The flow above also assumes that the application was provisioned via an MDM solution as it skips the need to enter the tenant name. If an MDM option is not possible (e.g. if you have a BYOD policy), then this is a one-time process, but you will need to communicate this to your staff accordingly.
As an example, if your site’s URL is https://mycompany.retailcloud.net, then you will need to ask your staff to type “mycompany” into the organization name field.
 |  |
User Logout
We've employed best practice session management. The behavior is as follows:
- Assuming the user doesn’t have a separate tab with a corporate session running when they log out of Frontline Portal, they are also automatically logged out of their corporate account.
- If their corporate session times out then they will also be automatically logged out of Frontline Portal; however, their corporate session will remain active if only their Frontline Portal session times out.
SSO Configuration
Frontline Portal employs the global standards OpenId / OAuth2 for SSO, and as such, we require the following details in order to enable SSO for your instance of Frontline Portal:
- OAuth2 Client Id (this is likely a long string).
- OAuth2 Client Secret (generated by your IdP for this specific integration, this is a long string).
For security reasons, we recommend that the above are sent in two separate emails, the secret in an encrypted form.
Depending on the IdP that you use, we also need to know the following:
- OAuth2 response type (could be either code, id_token, etc - our default setting is ‘id_token’).
- OAuth2 scopes (this will be agreed upon depending what unique staff identifier will be used, but it needs to match the name used in the scope e.g. openId, email).
Finally, we will need you to confirm the following web address endpoints:
- OAuth2 Issuer Endpoint
- OAuth2 Authorization Endpoint
- OAuth2 Token Endpoint
- OAuth2 Logout Endpoint
- OAuth2 Public Keys Endpoint
- Openid Configuration Endpoint
