Single sign-on (SSO) is an authentication method that enables users to log in with a single ID and password once and get access to multiple applications without additional credentials or logins. There are many vendors that offer SSO and Incorta integrates with several of them. This article will outline general SSO configuration within Incorta as well as some tips and best practices.
What you should know before reading this article
We recommend that you be familiar with these Incorta concepts before exploring this topic further.
These concepts apply to all releases of Incorta both on-premise and cloud.
Incorta's User Authentication Options
Incorta offers three ways to authenticate a user (authentication refers to the process that identifies the person attempting to access an application):
Incorta Authentication: Incorta's native authentication which leverages the Incorta Security user interface to manage users and groups
Single Sign-On (SSO): Offloading user authentication to a third party SSO provider
LDAP Authentication: Offloading user authentication to a third party LDAP provider
How Incorta Integrates With SSO Providers
Incorta supports several SSO providers including OneLogin, ADFS (both on-premise and Azure SSO), Okta, etc. Each SSO provider has its own particular implementation details but in general the process has this flow:
Within your SSO provider's admin console, add and configure Incorta as a new application
Create a configuration file as directed. Note that your IDP may have the ability to download a metadata XML file which contains values necessary for the configuration file.
Place the configuration file on your Incorta Analytics server (for example ./IncortaAnalytics/IncortaNode/sso)
Edit the Incorta Analytics server.xml file per your specific SSO provider's requirements
Restart the Analytics service
Incorta requires that even SSO users exist in the Incorta metadata repository prior to being allowed to access Incorta.
Users can be created manually in the Incorta Security UI. Remember to set the users' authentication type to "SSO" rather than "Incorta"
Users can be imported through an automated process either by integrating with LDAP, database, or flat file exports.
Customers using Incorta v4.9 and higher can enable the "Auto provision SSO users" feature in the CMC
Some SSO providers require the service provider (Incorta application) to be running HTTPS rather than HTTP
Please follow Incorta's documentation closely when integrating your SSO. Something that may seem trivial can prevent user authentication from working correctly.
For IDPs that require a certificate key pasted into the configuration file, make sure to not include any extra whitespace
For SAML-based IDPs Incorta requires the IDP be configured to include a parameter in the token called "loginName". Note that this is case-sensitive.
For SAML-based IDPs the loginName parameter must match the login name as configured in Incorta. This is usually the user's email address or directory login name. Note: for some IDPs, the login name stored in Incorta must match the case of the name in the SSO IDP.