This document is intended for an IT administrator and assumes that 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 is 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 move between 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. The client 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
To be compatible with D&A, your Idp must support the following:
- SP initiated SSO
- SAML 2.0
For example, here is a list of the third-party IdPs we already tested and validated:
- ADFS 2.0/3.0
- Windows Azure ADFS
What you need from inova to set up your connection
- Inova SP Metadata file
This Metadata file contains all the required informations to setup your IdP:
- Entity ID: our Inova UAT or PROD entity id, depending of the phase of implementation
- Security Token Consumer URL
- Public certificate
- User attributes to be sent over the SAML assertion
What Inova needs from your identity provider
- Your IdP Metadata file
What Inova needs in the SAML assertion sent by your IdP
- Login in Inova application is based on email address so it will be passed as NameID in the assertion
- The lastname
- The firstname
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 is not really an issue since Inova consumes a couple of non-confidential attributes like email address, givenName.
- Since the SPNameQualifier must be filled in the SAML response and IdP like Okta, PingId don’t provide this information the response passes through a SAML proxy in Inova infrastructure
The WebSSO implementation is made in two phases and in relation 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 validated we go on Production, implementing the tested configuration and setting Inova with WebSSO. Inova application needs to be restarted during this phase.
Most of the Idp like Okta, PingId only required a few set of parameters like:
- Entity ID
- Postback URL
- Target URL
Those parameters can be found in the Inova Metadata file.
With ADFS we need to create additional “claim rules” to add specific attributes 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 in Inova Software will give you all the details about those claim rules.