Hello! How can we help?
This document is intended for an IT administrator and assumes that the readers have a basic understanding of Active Directory as well as its Federation Service.
You will need the assistance of an Inova expert to help you activate webSSO for your organization.

Overview of Single Sign on with Inova

What Are SSO 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 Inova Support SSO?

Inova supports SSO via SAML 2.0 and acts as a service provider (SP) for SSO. You must implement a federation service to act as an identity provider (IdP). Federation can be accomplished through an in-house or third-party provider.

Setting Up Single Sign On

IdP Requirements

To be compatible with D&A, your IdP must support the following:

  • SP initiated SSO
  • SAML 2.0

For example, here's a list of the third-party IdPs we've already tested and validated:

  • ADFS 2.0/3.0
  • PingFederate/PingOne
  • Okta
  • Microsoft Azure AD
  • SailPoint
  • OpenAM
  • VMWare ID

What You Need From Inova to Set Up Your Connection

  • A quick configuration document for specific requirements.
  • Inova SP Metadata file.

This Metadata file contains all the required information to set up your IdP:

  1. Entity ID: our Inova UAT or PROD entity id, depending on the phase of implementation.
  2. Security Token Consumer URL.
  3. Public certificate.
  4. User attributes to be sent over the SAML assertion.

What Inova Needs From Your Identity Provider

  • Your IdP Metadata file.
  • A test account to facilitate and accelerate the implementation.

What Inova Needs in the SAML Assertion Sent by Your IdP

  1. Logging in to the Inova applications is based on the email address so it will be passed as NameID in the assertion.
  2. The last name.
  3. The first name.
  4. The email.

Limitations Depending on Your IdP

  • The authentication request is not signed by default.
  • The SAML assertion must be signed.
  • We don’t use encryption for the SAML assertion (possible with ADFS). It's not really an issue since Inova consumes a couple of non-confidential attributes like email address and given name.
  • Since the SPNameQualifier must be filled in the SAML response, and IdP like Okta or PingId don’t provide this information, the response passes through a SAML proxy in the Inova infrastructure.

Implementation Steps

The WebSSO implementation is made of two phases with your IT experts. To secure our production environment we first configure and test the WebSSO on a UAT environment. During this step, we define the right configuration and fix any issue that could happen during the authentication workflow.

Once everything is validatedn we go on production, implementing the tested configuration and setting Inova with WebSSO. The Inova application needs to be restarted during this step.

Specific IdP Information

Most of the IdP like Okta or PingId only required a few sets of parameters like:

  • Entity ID
  • Postback URL
  • Target URL
  • Certificates

Those parameters can be found in the Inova Metadata file.

With ADFS we need to create additional “claim rules” to add specific attributes that we need for the Service Provider:

  • A claim rule to set the spNameQualifier and namequalifier in the response.
  • A claim rule to set the authentication mode “Password Protected Transport”.

During the implementation steps, your contact at Inova Software will give you all the details about those claim rules.