Configuring Single Sign-On (SSO)
Who is this article for?
Hub Administrators configuring Ideagen Hub for single sign-on (SSO).
IT Administrator access is required.
This article explains how to configure Single Sign-On (SSO) within Ideagen Hub.
Some steps require input from your IT team, who manage your organisation's identity provider (the system that controls company logins). These steps are clearly highlighted throughout this guide.
1. Overview
Single Sign-On (SSO) allows your users to access Ideagen applications using the same credentials they already use for your organisation's network - rather than managing a separate username and password.
Clicking it takes them directly to your company's sign in page. Users who are not set up for SSO can still log in using their email address and password as normal.
The key benefits of enabling SSO include:
- Seamless experience - Users sign in once and don't need a separate application password.
- Centralised identity management - Your IT team controls access from one place.
- Improved security and compliance - Authentication is handled by your organisation's identity systems.
- Fewer support requests - No more forgotten application passwords.
2. Preparing for setup
Configuring SSO involves connecting two systems: Ideagen Hub and your organisation's identity provider (IdP) - the service that manages your company logins (for example, Microsoft Entra ID, Google Workspace, or Okta).
Both sides must be properly configured to work together. Your IT team manages your identity provider and holds key technical details like metadata or client credentials. We suggest contacting them beforehand so they can prepare the necessary information.
The application supports two SSO protocols:
- SAML 2.0 - The most common choice, supported by Microsoft Entra ID, Okta, Google Workspace, and Keycloak, among others.
- OIDC (OpenID Connect) - A more modern protocol, also widely supported.
Your IT team will advise which protocol your organisation's identity provider uses.
Note
SSO is disabled by default on all Ideagen systems. You must complete the configuration steps below to enable it.
2.1. Gathering information
Before starting the configuration, ask your IT team to provide the following information depending on your chosen protocol. You may find it helpful to share this section with them directly.
2.1.1. SAML
Let your IT team know that you will be able to provide them with the following from within the application configuration screens:
- Entity ID (also called Identifier)
- Reply URL (also called the ACS URL - Assertion Consumer Service URL)
- Signing certificate
- Encryption certificate
Ask your IT team to provide:
- A metadata document or metadata URL for your identity provider (the metadata URL is recommended).
- Whether to enable Single Sign-Out (simultaneous logout from both Ideagen Hub and the identity provider when a user signs out).
- Whether to enable signing of SAML requests.
- Whether to require encrypted SAML assertions.
- The name of the attribute that contains the user's email address in your identity provider.
- The name of the attribute that holds a unique and unchanging user ID (such as a network GUID).
Note
In most cases, the email attribute mapping will simply be email to email. However, some identity providers (particularly Microsoft Entra ID) may use a full URL as the attribute name — your IT team will know which applies to your setup.
2.1.2. OIDC
Let your IT team know that you will be able to provide them with the following from within the application configuration screens:
- Redirect URI
- Signing certificate
OIDC connections typically doesn't require a signing certificate.
Ask your IT team to provide:
- Client ID.
- Client Secret.
- Authorised scopes.
- Whether to use GET or POST for the attribute request method.
- Issuer URL (the application can use this to automatically retrieve remaining settings).
- If they prefer to set endpoints manually, ask for: Authorisation endpoint, Token endpoint, UserInfo endpoint, and JWKS_URI.
- The name of the attribute that contains the user's email address in your identity provider.
- The name of the attribute that holds a unique and unchanging user ID (such as a network GUID).
Note
In most cases, the email attribute mapping will simply be email to email. However, some identity providers (particularly Microsoft Entra ID) may use a full URL as the attribute name. Your IT team will know which applies to your setup.
3. Configuring SSO
Once you have the information from your IT team, you can configure SSO in the app.
To configure SSO:
- Log in to Ideagen Hub as a Tenant Administrator.
- Open the Admin Console.
- Select Security Centre.
- Click Authentication to expand the menu.
- Select Configure next to the External IDP Configuration option.
- Click Add Identity Provider.
- Select SAML or OIDC depending on what your IT team advised.
- Click Next.
- Fill in all mandatory fields (marked with a red asterisk).
See the relevant section below for field-by-field guidance. - Click Apply configuration when complete.
Note
If an identity provider has already been configured for your tenant, you can either update the existing settings, add an additional provider or delete the existing one and start again.
3.1. Configuration details
3.1.1. SAML
On the SAML configuration screen, you will be able to see the Entity ID and Reply URL - share these with your IT team if they need them to configure your identity provider.
Next, complete the following fields.
| Field | Description |
|---|---|
| Provider name | A friendly label to help you recognise this connection. For example, Company SSO or Okta Login. This name will appear as the button you can click to sign in using your Corporate ID on the Hub login screen. |
| Sign-out flow | Enable this if your IT team confirmed they want simultaneous sign-out from both Ideagen and the identity provider. See the known limitations table for what is supported by common identity providers. |
| Metadata document source | Either paste in the metadata URL (recommended) provided by your IT team, or upload the metadata XML file they provided. |
| SAML signing and encryption | Configure signing and encryption based on what your IT team advised. See the known limitations table for what is supported by common identity providers. |
| Attribute mapping - email |
Map the email user pool attribute to the attribute name used by your identity provider. In many cases this is simply email. You can find more details on how to complete the attribute mapping in our articles for external identity providers:
You should then find that your assertion statement contains a name with that attribute, e.g.: |
| Attribute mapping - preferred_username | This field appears for organisations provisioned on release 5.2 or later. Map this to any attribute that represents a unique identifier for the user in your organisation. This does not have to be an email address. Ask your IT team which attribute to use (for example, a network user GUID). |
3.1.2. OIDC
On the OIDC configuration screen, you will be able to see the Redirect URI and a signing certificate - share these with your IT team if needed.
Next, complete the following fields.
| Field | Description |
|---|---|
| Provider name | A friendly label to identify this connection. For example, Company SSO. This is for your reference only. |
| Client ID | Provided by your IT team. |
| Client Secret | Provided by your IT team. |
| Authorised scopes | Provided by your IT team. Separate scopes with spaces. |
| Attribute request method | Choose GET or POST as directed by your IT team. |
| Issuer URL / Manual input |
Choose one option:
|
| Attribute mapping |
Map the email user pool attribute to your email address attribute name. Map the preferred_username user pool attribute to any attribute that represents a unique and unchanging username for your organisation. |
5. Configuring users for SSO
Once SSO is configured, you need to update your users so they can use it. There are two ways to do this:
- Manually editing each user.
- Using the CSV import mechanism to update all users at once.
In both cases, you want to change the Authentication Type to External for each user:
We strongly recommend keeping at least one administrator account that does not use SSO. If there is ever a problem with your SSO configuration, you will still be able to log in and make changes.
6. Signing in with SSO
Once SSO is configured and users have been updated, the Hub login screen will show an SSO button alongside the standard email and password fields. Users set up for SSO can click this button to be directed to your organisation's sign in page.
Users who have not been switched to SSO can continue to log in using their email address and password as before.
InPrivate/Incognito browsing issues
Some users may experience difficulty logging in via SSO when using a private browsing window. This is because your identity provider may rely on session cookies from other corporate applications that are not available in private mode. If this happens, ask your IT team to add Ideagen Hub to any session bypass lists or exclusion policies.
7. Known limitations
The table below summarises the known limitations for common identity providers when using the SAML protocol. Your IT team may find this useful when deciding on configuration options.
| SAML Feature | Available in Hub | IDP | Supported by IDP | Notes |
|---|---|---|---|---|
| Single Sign-Out | Yes |
Microsoft Entra | No | Requires LogoutResponse via HTTP POST; Entra only supports HTTP GET. |
| Okta | Yes | |||
| Google Workspace | No | Does not support Single Sign-Out. | ||
| IDP-Initiated | No |
Microsoft Entra | Yes | Currently investigated for future roadmap. |
| Google Workspace | Yes | |||
| SP-Initiated | Yes |
Microsoft Entra | Yes |
|
| Okta | Yes | |||
| Google Workspace | Yes | Attribute must be mapped using the exact app attribute name specified in Google Workspace. | ||
| Require encrypted SAML assertion | Yes |
Keycloak | Yes | |
| Google Workspace | No | Does not support SAML encryption. | ||
| Microsoft Entra | Yes | |||
| Attribute Mapping | Yes |
Keycloak | Yes | |
| Microsoft Entra | Yes |
Attribute may need to be mapped with full URI format depending on the customer's IDP configuration. For example. to map email address, the OpenID Connect attribute may be entered as: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress or just emailaddress or any other name the customer's organization has defined as the claim name for the user.email value. |
||
| Okta | Yes | |||
| Google Workspace | Yes | |||
| Sign SAML Request | Yes |
Google Workspace | No | Does not support Sign SAML request. |
Note
The table reflects known limitations at the time of writing. Your specific configuration may reveal additional considerations. Ideagen continues to investigate expanded support for features such as IdP-Initiated login.