SAML SSO Authentication - Implementation Guide

Objective

Make your operators' lives easier by allowing them to authenticate within iAdvize from their own centralized authentication system (Identity Provider).

Use case

If the operators have to switch between several apps (including iAdvize) during their daily work, SAML is one of the most recognized SSO protocols in the market today and is very well spread across large companies. It allows customers to authenticate their users within iAdvize by using their own centralized authentication system (Identity Provider).

SAML authentication can be useful for two main reasons:

• security: it allows customers to authenticate their users into multiple tools with only one centralized user account for each user(thus requiring one login/password only), and to parameter user authentication and authorizations to multiple tools from a single authentication system.

• user deployment: it allows customers to onboard lots of users (hundreds or thousands) easily and quickly without the need for creating and handling specific user/password for each of them. It’s based on the domain controller/Active Directory/database users’ password.

Process

If you are interested in using the SSO SAML Authentication, please get in touch with your Customer Success Manager.

Prerequisites: create your users

iAdvize uses the email address as a unicity key so it has to be unique.

The user email address has to be the same between iAdvize and your Identity Provider.

Please do not hesitate to read our article about how to create or edit a user.

The users must be also created on the domain controller/Active Directory/database beforehand.

Implementation steps

Configuring the connection

Here are the following steps to fulfill in order to configure the connection:

Share with us your SAML certificate	> X509 Signing Certificate - i.e. the Identity Provider public key encoded in PEM or CER format
Provide us your sign-in URL	> i.e. the URL where users signs in to the Identity Provider
Expose the email of your user as a Name ID or specific SAML attribute	> iAdvize uses the email to map your users to iAdvize users
(optional) Send us your email domain to force users to use SSO	> That is applicable only if you want to use mobile application and/or you do not want to use SAML direct link or to avoid login/password connection

Connecting a user

There are two login options. If you do not know which one is more suitable to your use case, please discuss it with your Customer Success Manager and the Technical Project Manager involved in the project.

Login through a direct link

It is possible to generate and use a direct link to log in a user straight into iAdvize ;the generated link follows this convention :

https://ha.iadvize.com/admin/login?connectionId=saml-ha-<clientID>

When a user tries to log in using such a link, if he is already connected to your Identity Provider system, he is automatically redirected and connected to iAdvize (if not connected yet, he is requested to login to the IdP prior to being redirected and logged in to iAdvize).It is very useful, especially for integrations, and it simplifies the process of onboarding customers onto SAML as it avoids the need for changes in the Admin codebase (see more details about this below).The direct link is the preferred option to connect to iAdvize with SAML. Note that the link cannot be used on mobile apps.

Login through iAdvize login page It is also possible to use the SSO authentication redirection while login in to iAdvize from the standard login page at https://ha.iadvize.com. In this case, the domain of the email the user logs in with is used as a key to trigger the connection via SAML i.e. every user belonging to the domain on which SAML has been activated is redirected to the IdP configured for that domain at login. This is the only SAML option at the time on mobile apps. At the end, it looks like this:

Current limitations

• logout is not available

• no auto-provisioning (you can create iAdvize users through API)

• no IdP-initiated - only SP-initiated (for security reasons)