ITRP can be configured to use an organization’s existing identity provider (such as Microsoft Active Directory, OneLogin, the Okta Application Network, etc.) instead of ITRP’s own authentication mechanism to determine whether a user should be given access to ITRP.
By using an existing identity provider, the organization’s ITRP users (including the end-users who need to be able to use Self Service) will not require a separate password to access ITRP.
SAML-based Single Sign-On Transaction Steps
The image above illustrates the following 10 steps that complete one SAML-based SSO transaction:
The user attempts to access the ITRP account of his/her organization using a browser application such as Microsoft Internet Explorer, Google Chrome, etc.
ITRP looks up the settings of the ITRP account of the user’s organization and sees that SSO has been configured in this account. That is why, rather than prompting the user for an email address and password, ITRP generates a SAML authentication request. ITRP then encodes this SAML authentication request and embeds it into a redirect URL that is intended for the SSO service of the identity provider that the user’s organization uses. Also embedded in the redirect URL is the encoded destination URL within the ITRP account that the user is trying to reach.
ITRP sends the redirect URL to the user’s browser.
The user’s browser redirects to identity provider’s SSO service.
The identity provider decodes the SAML request and extracts the destination URL. The identity provider then authenticates the user.
The identity provider generates a SAML response that contains the authenticated email address of the user and the destination URL. In accordance with the SAML 2.0 specification, this response is digitally signed with the identity provider’s public and private DSA/RSA keys.
The identity provider encodes the SAML response along with the user’s email address and destination URL, and provides a mechanism so that the user’s browser will forward this information to ITRP.
The user’s browser forwards the encoded information to ITRP.
ITRP verifies the SAML response using the SHA1 fingerprint of the identity provider’s SAML certificate.
If the response is successfully verified, ITRP redirects the user to the destination URL within the ITRP account of the user’s organization. The user is now logged in to ITRP.
How to Enable SSO for ITRP
To make SSO work for an organization’s ITRP account, the ITRP account owner will need the following information:
the remote login URL of the organization’s identity provider (also known as the SAML Single Sign-On URL),
the SHA1 fingerprint of the identity provider’s SAML certificate.
This information can then be entered by the ITRP account owner in the Single Sign-On section of the Settings console.
Once SSO has been enabled, the account owner can check whether it works by logging out of ITRP and subsequently trying to access ITRP again by going to the URL of the ITRP account. If the account owner is already logged in to the identity provider, ITRP should no longer ask for an email address and password. Instead, the account owner is directly taken to the ITRP inbox.
Using the SSO Configuration of the Directory Account
Support domain accounts are able to use the single sign-on configuration of their directory account. After SSO has been enabled in a directory account, the checkbox ‘Login using SSO configuration of directory account’ becomes available.
Checking this box hides the SAML SSO URL field as well as the Certificate fingerprint field. The values for these fields are obtained from the directory account when this feature is in use.
Secure Hash Algorithm
The following secure hash algorithms are supported by ITRP:
If SSO has been enabled for an ITRP account, but it does not appear to work, then the account owner can access ITRP again by adding
/access/normal to the URL of the ITRP account. Once the owner is back in ITRP, the System Logs section of the Settings Console can provide some useful information about why SSO is not working. Whenever there has been an authentication failure, an entry will have been added to the log with an explanation of what went wrong.
Another useful source of information is the SAML meta data.
Also keep in mind that the clock of the servers of the identity provider need to be synchronized. If the clock is more that 2 seconds out of sync, the SAML response from the identity provider will not be accepted by ITRP.