New article
Recently updated
Configuring single sign-on (SSO) for Ideagen Hub
Who is this article for?
Hub Administrators configuring Ideagen Hub for single sign-on (SSO).
IT Administrator access is required.
This guide is for Hub Administrators who are responsible for configuring 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.
What is SSO and why use it?
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.
Once configured, users will see an SSO button on the login screen.
Clicking it takes them directly to your company's login 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.
Before you begin
Setting up 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, Okta, or Google Workspace).
Think of it like connecting two puzzle pieces — both sides need to be configured correctly for them to work together.
You will need your IT team's involvement. Your IT team controls your identity provider. There are specific pieces of technical information (such as metadata or client credentials) that only they can provide. We recommend contacting your IT team before you start so they know what to expect and can prepare the information you need.
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.
Information to gather from your IT team
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.
For 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.
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 on attribute mapping: 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.
For 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.
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 on attribute mapping: 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.
Configuring SSO in the application
Once you have the information from your IT team, follow these steps to open the SSO configuration screen:
- Log in to Ideagen Hub as a tenant administrator.
- Open the Admin Console.
- Select the Security Centre icon.
- Click on Authentication to expand the menu.
- Click Configure next to the External IDP Configuration option.
- Click Add Identity Provider.
- Select SAML or OIDC depending on what your IT team advised, then 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.
SAML configuration details
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.
Complete the following fields:
| Field | What to enter |
|---|---|
| Provider name | A friendly label to identify this connection — for example, "Company SSO" or "Okta Login". This is for your reference only and does not affect how SSO works. |
| 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 section — not all identity providers support this. |
| 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 Microsoft Entra ID: Entra ID sends email by default. The SAML Attribute value to set is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Okta and others: 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 the application, set the SAML attribute to email:
|
| 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). |
OIDC configuration details
On the OIDC configuration screen, you will be able to see the Redirect URI and download a signing certificate — share these with your IT team if needed.
Complete the following fields:
| Field | What to enter |
|---|---|
| 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. |
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 SSO user:
For information on using the CSV file import, see this article: Importing and exporting users.
Important — Keep a fallback administrator 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.
Logging 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 login page.
Users who have not been switched to SSO can continue to log in using their email address and password as before.
A note on Private / InPrivate browsing: 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.
Known limitations by identity provider
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 Signout | 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. | |
| 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 e.g. 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 | Google Workspace | No | Does not support Sign SAML request. |
Note: The table above 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.