Single Sign-On (SSO) Overview

Single sign-on (SSO) allows an organization to centralize user management and permissions granting for their employees or partners. It provides convenience for the end user by allowing them to access multiple systems with a single login.

SSO can be set up with your ion console as a project to allow you to use your preferred Identity Provider as a way to access to your ion console instead of setting up separate logins.

If you are interested in setting up SSO for your ion console, please reach out to your dedicated customer success manager to discuss next steps. You can also click here to review pricing information for SSO implementation.

SSO Options

A single sign-on integration can be set up in ion to provide access to the main console admin, sell-side experiences and live creatives.

ion console admin

Simplify sign-on and consolidate user management by setting up SSO for those working in your ion console.

Each role may have access turned on or off for the following areas:

Data collection (data fields, choice sets, validation patterns)

Data sources (lookup tables)

Email template library

Form library

Framework library

Fulfillment library

Image library

Integrations

Portfolios (all)

Script library

Scriptlet library

Snippet library

Tag library

Widget library

Sell-Side experiences

Instead of looking at data collected in a series of fields in your CRM, you can export a single link which allows your team to view the the user’s interactions within the context of the actual pages they viewed. Since an ion login is required to view this content, SSO can help you scalably manage access for large teams.

Live creatives

SSO for live creatives allows you to gate access to an ion URL with a user login.

This feature is a convenient way to manage access to content that should be accessible to employees only. SSO for live creatives may be turned on or off at the creative level.

Note: Roles with SSO access to live creatives will be able to view all URLs with this feature enabled. We do not support more granular role definition for live creative SSO at this time.

Implementation

There are many different protocols that can be used to implement SSO. One of the most popular protocols, and commonly used with ion, is SAML. Read on to get an overview of how a SAML SSO integration with ion works.

SAML Overview

SAML is "an XML-based framework for authentication and authorization between two entities: a Service Provider and an Identity Provider."

What is a Service Provider?

Auth0 defines a Service Provider as an "application that provides services to other entities." Think of it as the system that kicks off the request for authentication and then processes the response. In the case of ion, Auth0 is the Service Provider and the relationship with Auth0 is owned and managed by ion.

What is an Identity Provider (IdP)?

Auth0 defines an Identity Provider as a "website, app, or service responsible for coordinating identities between users and clients. An IdP can provide a user with identifying information and serve that information to services when the user requests access." The Identity Provider is the identity system owned and managed by an ion customer, for example: Azure (AD), ADFS, or CA Single Sign-on.

In a SAML SSO integration, authentication information is exchanged through digitally signed XML documents.

Below you will find an example of the workflow when using SSO to access the ion admin console:

The user clicks to login with SSO.

⬇

The user is presented with a link to the SSO destination.The user clicks to continue.

⬇

The Service Provider generates a SAML request and the browser redirects the user to the SSO login URL.

⬇

The Identity Provider (IdP) parses the SAML request and authenticates the user.The IdP generates a SAML response which is returned to the Service Provider.The Service Provider parses the SAML response and uses those details to establish appropriate access.

The response generated by the Identity Provider can be called an Assertion. Assertions contain information about the user that the Service Provider will use to establish appropriate access. In the the case of ion, we’ll ask you to include role names (sometimes called "group membership" or similar) set in your Identity Provider in the Assertion. These roles will be mapped to the permissions in ion you specify.

For example, users with role ionAdmin might have different access than users with role ionEditor.

These roles may be called whatever you like, and you have some configuration options available in terms of their access.