Skip to main content

How to Configure Single Sign-On?

This document is intended for an IT Administrator and assumes that the readers have a basic understanding of Single Sign-On.

What is Single Sign-On and its benefits?

The Single Sign-On (SSO) Authentication allows a user to access multiple applications with a single set of credentials.
The advantages are multiple: users can navigate applications securely without specifying their credentials each time, thus saving time and reducing the risk of forgetting their password.

Does Inpart Support SSO?

Inpart supports SSO via the OpenID Connect (OIDC) 1.0 protocol and acts as a Service Provider (SP).

We have decided to rely on the OpenID Connect 1.0 protocol instead of SAML 2.0 because of all the benefits OIDC offers (ease of implementation, security, etc.).
Moreover, with OIDC, we no longer need to manage certificates as we did before with SAML. Instead, we use a client ID and a client secret.

If your security policy does not allow you to use the OIDC protocol, we can adapt and use the SAML 2.0 protocol instead. But we would prefer that this remain an exception where possible.
Please contact your Customer Success Manager or Inpart Support to find out how to proceed.

Setting Up Single Sign On

Identify Provider Requirements

Please ensure that Inpart’s domain is whitelisted on your end.


To help you configure your IdP, please find below detailed procedures to download and a summary table.

IdP Elements you will need from us for your setup Elements to send to Inpart

Microsoft Azure AD

Detailed procedure

Redirect URI:<realm_name>/broker/oidc-azure/endpoint

1. OpenID Connect metadata document

2. Application (client) ID

3. Client secret

4. Client secret Expiration Date


Detailed procedure

Redirect URI:<realm_name>/broker/oidc-okta/endpoint


Sign-out redirect URIs:<realm_name>/broker/oidc-okta/endpoint/logout_response

1. Client ID
2. Client secret
3. Okta domain

AD FS 2016 and later

Detailed procedure

Redirect URI:<realm_name>/broker/oidc-adfs/endpoint 1. Client Identifier
2. Client secret
3. ADFS OpenID Connect Metadata file URL (e.g. https://<your-domain>/adfs/.well-known/openid-configuration)

CyberArk Idaptive

Detailed procedure

Redirect URI:<realm_name>/broker/oidc-idaptive/endpoint


Resource application URL: https://<realm_name>

1. Client ID
2. Client Secret
3. Metadata URL


Detailed procedure

Redirect URI:<realm_name>/broker/oidc-onelogin/endpoint


Login URL: https://<realm_name>

1. Client ID
2. Client Secret
3. Issuer URL (Well-known Configuration)

Ping Identity

Detailed procedure

Redirect URI:<realm_name>/broker/oidc-ping/endpoint 1. OIDC Discovery Endpoint
2. Client ID
3. Client Secret

VMware ONE Access

Detailed procedure

Redirect URI:<realm_name>/broker/oidc-vmware/endpoint


Target URL: https://<realm_name>

1. Client ID
2. Client Secret
3. OpenID Connect metadata URL. It should look like that:


Detailed procedure

Redirect URI:<realm_name>/broker/oidc-keycloak/endpoint 1. Client ID
2. Client Secret
3. OpenID Endpoint Configuration URL

Google Cloud Platform (GCP)

Detailed procedure

Redirect URI:<realm_name>/broker/oidc-gcp/endpoint 1. Client ID
2. Client secret
Please replace <realm_name> by your actual realm name.
You'll find it at the beginning of the URL you use to access your Inpart application.
So for example, if the URL of your production environment is, then your realm name will be inpart.
For other IdPs or if you have any doubts on how to get this Redirect URI, please contact your Customer Success Manager or Inpart Support.

Implementation Steps

If you have a test environment (UAT), we will start by implementing SSO on that environment.
Once everything is validated on UAT, we do the same on Production.

Steps Who? What?
1 You Start the setup on your IdP by following the appropriate procedure and then send us the elements we need.
2 Inpart Continue the set up on our Authentication System and then send you a test link which aims to validate with you that the configuration is correct on both sides.
3 You

Validate the test link by following the instructions below:


1. Click on the following test link:<realm_name>/account/#/applications

Please replace <realm_name> by your actual realm name, see the explanations here.


2. Once the login page loaded, add the following string to the end of the URL generated and then press enter:

- For Microsoft Azure AD, add this string: &kc_idp_hint=oidc-azure

- For Okta, add this string: &kc_idp_hint=oidc-okta

- For ADFS, add this string: &kc_idp_hint=oidc-adfs

- For CyberArk Idaptive, add this string: &kc_idp_hint=oidc-idaptive

- For OneLogin, add this string: &kc_idp_hint=oidc-onelogin

- For Ping Identity, add this string: &kc_idp_hint=oidc-ping

- For VMware ONE Access, add this string: &kc_idp_hint=oidc-vmware

- For Keycloak, add this string: &kc_idp_hint=oidc-keycloak

- For Google Cloud Platform (GCP), add this string: &kc_idp_hint=oidc-gcp


Example for Okta:



3. If everything goes well, you should be redirected to your IdP's login page to enter your credentials and then land on a test page that looks like that (your first and last name should be visible in the upper right corner):



4. However, you may face a page saying that your account already exists:


In this case, this is normal and expected. Please click on “Add to existing account”. You will then receive an email from the Inpart Authentication System with a link inside. Please check your mailbox and click on the link provided.


You should land on the test page and see your first name and last name on the top right corner.

4 You/Inpart If the test link does not work as expected, inform Inpart of the error message you are getting and correct any issues that may arise during the authentication flow (most often these are mapping issues or incorrect client secret sent to Inpart).
5 You If the test link works as expected:
1. Confirm the result to Inpart. If possible, add a screenshot of the test page you get.
2. Please also confirm to Inpart that you have authorized the desired users/groups to use the new application(s) you just created in your IdP. It is very important that this is done before enabling SSO, otherwise, no one will be able to log in.
6 Inpart/You Check on our Authentication System that there is no mapping issue. It is very important that the username transmitted by your IdP is equal to the email address to avoid any issue.
- If all is well, go to the next step.
- Otherwise, keep you informed of the mapping issue so that you can fix it.
7 Inpart

Schedule with you the date & time on which the SSO will be activated.

- No intervention is required by you for this step.

- It will take about 1 hour, your application will be unavailable during this time.

- We usually arrange to do this at a time that will cause the least disruption to users.

8 Inpart Inform you as soon as the SSO is activated.
9 You Validate that everything is working properly and that users can log in successfully. Please send a confirmation to Inpart.
If SSO is already enabled for your applications and you want to change your identity provider, the procedure is the same.
Was this article helpful?
0 out of 0 found this helpful
In this article

Other articles in this section