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 auth.inova-application.com is whitelisted on your end.
Procedure
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 |
Redirect URI: https://auth.inova-application.com/auth/realms/<realm_name>/broker/oidc-azure/endpoint |
1. OpenID Connect metadata document 2. Application (client) ID 3. Client secret 4. Client secret Expiration Date |
|
Okta |
Redirect URI: https://auth.inova-application.com/auth/realms/<realm_name>/broker/oidc-okta/endpoint
Sign-out redirect URIs: |
1. Client ID 2. Client secret 3. Okta domain |
|
AD FS 2016 and later |
Redirect URI: https://auth.inova-application.com/auth/realms/<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 |
Redirect URI: https://auth.inova-application.com/auth/realms/<realm_name>/broker/oidc-idaptive/endpoint
Resource application URL: https://<realm_name>.partneringplace.com/inova-partner |
1. Client ID 2. Client Secret 3. Metadata URL |
|
OneLogin |
Redirect URI: https://auth.inova-application.com/auth/realms/<realm_name>/broker/oidc-onelogin/endpoint
Login URL: https://<realm_name>.partneringplace.com/inova-partner |
1. Client ID 2. Client Secret 3. Issuer URL (Well-known Configuration) |
|
Ping Identity |
Redirect URI: https://auth.inova-application.com/auth/realms/<realm_name>/broker/oidc-ping/endpoint |
1. OIDC Discovery Endpoint 2. Client ID 3. Client Secret |
|
VMware ONE Access |
Redirect URI: https://auth.inova-application.com/auth/realms/<realm_name>/broker/oidc-vmware/endpoint
Target URL: https://<realm_name>.partneringplace.com/inova-partner |
1. Client ID 2. Client Secret 3. OpenID Connect metadata URL. It should look like that: https://<your-url>/SAAS/auth/.well-known/openid-configuration |
|
Keycloak |
Redirect URI: https://auth.inova-application.com/auth/realms/<realm_name>/broker/oidc-keycloak/endpoint |
1. Client ID 2. Client Secret 3. OpenID Endpoint Configuration URL |
|
Google Cloud Platform (GCP) |
Redirect URI: https://auth.inova-application.com/auth/realms/<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 https://inpart.partneringplace.com/inova, 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: https://auth.inova-application.com/auth/realms/<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.