Hub Single Sign On SSO in Please Review
Who is this article for?
Application administrator permissions are required to configure the Hub application.
IT administrator permissions are required to configure the Identity Provider.
Summary
Single Sign-On (SSO) allows you to use your network credentials to login to Please Review, instead of a separate username and password.
This article describes the process for setting up SSO in the application.
After successfully configuring SSO, when a user visits the login screen they will see a dialog box like this:
Users logging in with SSO will be able to click the SSO button and progress to the corporate login page, and users not using SSO will be able to sign in using the Email and Password boxes.
Before You Begin
Setting up SSO involves configuring two things: our application and your organisation's identity provider (the system that manages your company logins). Think of it like connecting two puzzle pieces—both sides need to be set up correctly for them to fit together.
You'll need help from your IT team to complete this setup. Before you start, you'll need to gather some specific information from them about your identity provider. This isn't something you can configure on your own—your IT team controls access to the login system and will have the technical details you need.
We recommend reaching out to your IT team first to let them know you're setting up SSO. They can provide the necessary information and may want to be involved in the configuration process to ensure everything is set up securely.
Once you have the required information from your IT team, you'll be ready to begin the configuration steps below.
Questions for the IT administrator
The application supports both SAML and OIDC. The first step is to decide which to use.
For SAML
The application administrator is able to download a signing certificate and find the Entity ID and the Reply URL (the ACS URL) from within the application configuration screens (see below).
The following information is required:
- Do you want to enable simultaneous sign out from your SAML provider and the application, when a user signs out?
- Either a metadata document, or the URL of your metadata endpoint
- We can sign SAML requests. Should this be on or off?
- We can require encrypted SAML assertions from the provider. Should this be on or off?
Note: normally, attribute mapping will be email <-> email.
Note also that SSO users will require some other unique ID. This could be their network user GUID, or any other value guaranteed to be unique.
If using OIDC
The application administrator is able to download a signing certificate and find the Redirect URI from within the application configuration screens (see below).
The following information is required:
- Client ID
- Client secret
- Any authorised scopes
- Whether to GET or POST
- Issuer URL. We assume that we will pull further information automatically, however you can also manually set:
- Authorisation endpoint
- Token endpoint
- UserInfo endpoint
- JWKS_URI
Note: normally, attribute mapping will be email <-> email.
For the application administrator: configuring SSO in the application
- Log into Ideagen Hub as an Ideagen Audit And Risk tenant administrator
- Select the Security Centre icon on the left side menu
- Click on Authentication to expand the menu
- Against At External IDP Configuration click Configure
- Click on Add Identity Provider
- Select SAML or OIDC, and click Next
Configuring for SAML
On this page you can find the Entity ID and Reply URL.
Enter the following information:
| Item | Note |
| Provider name | This is a label or nickname that helps you identify this connection. This is just for your reference and can be anything that makes sense to you, like "Company SSO" or "Okta Login." It won't affect how SSO works. |
| Sign-out Flow | Select to enable simultaneous sign-out from the SAML provider and Ideagen. |
| Metadata document source | Either upload a metadata file, or supply the URL of your metadata |
| SAML signing and encryption | The signing/encryption settings required by your identity provider |
| Map attributes . . . |
You must specify an email attribute. Example: Microsoft Entra ID Entra ID will send this by default. The SAML Attribute value to set is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress For preferred_username, if this field is required, this should be attribute for the user principal name, as this is the unique identifier in Azure. So this would be http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name e.g.
Other systems (e.g. Okta) You should ensure that your IdP is configured to send an email attribute. Not all IdP's will do this by default. The SAML attribute value should be the name of the of the attribute you send. For example, in Okta, add an Attribute Statement with the name 'email':
You should then find that your assertion statement contains a name with that attribute, e.g.: In addition to the above, in the latest version of Hub, the attribute mapping for should have 'login' to 'user.login'. In the application, set the SAML attribute to email:
|
Note that depending on the version of Hub you are using you may see other fields and we will aim to update this document as fields change. Preferred_username is one such field not required in the earlier versions of Hub.
After you have entered the required information, click Apply configuration.
Configuring for OIDC
On this page you can find the Redirect URI and download a signing certificate.
Enter the following information:
| Item | Note |
| Provider name | This is a label or nickname that helps you identify this connection. This is just for your reference and can be anything that makes sense to you, like "Company SSO" or "Okta Login." It won't affect how SSO works. |
| Client ID | |
| Client Secret | |
| Authorised scopes | |
| Attribute request method | |
| Auto fill through issuer URL / Manual input |
Choose one of these. If you specify Manual input, then you will need to additionally specify:
|
| Issuer URL | |
|
Normally, both of these boxes should contain the word email: For preferred username, if this field is required, this would be the unique field for identifying the user on the external system and this is likely to be login for Okta: |
After you have entered the required information, click Apply configuration.
Configuring users for SSO
In order to set up a user to use SSO, you can either:
- Add a new user, or
- Update an existing user
In both cases, the procedure is the same:
- Create an import CSV file containing the user(s) to add/edit.
- Ensure that the AuthenticationType value is set to External.
- Upload the file.
See Importing and exporting users – Help | Ideagen Luminate for further details.
Consider having one or more administrators who do not use SSO, for situations where there is a problem with SSO.