SSO (Single Sign-On) Configuration and Use

Source:

Published:

Keywords: SSO, Single Sign-On, Certain

Document ID: https://platform-support.certain.com/hc/en-us/articles/30685253237015#split1

This topic is an overview of how to configure and use an SSO (“Single Sign-On”) in Certain.

Certain can create SSO connections for you. Ask your Customer Success Manager for details.

These SSOs can include Social Logins (LinkedIn, Facebook, Microsoft, or Google+) and Corporate SSOs.

There are three types of SSO:

See .

See .

See .

See .

See .

Use the app to check attendees in at an event.

See .

"Admin" SSOs

An “Admin” SSO allows Certain users to log in without using their Certain username and password.

If Certain has configured an “ADMIN” SSO for a system (on ), then users of the Certain platform who signed in to the corporate system do not have to enter another user name and password to access Certain. Users still need a matching record in Certain.

> Note: Only one ADMIN SSO can be activated for a system at any one time.

"Attendee Login" SSOs

An “Attendee Login” SSO is for attendees logging in to registration forms or the Mobile web app. The SSO also applies to speakers logging in to a Speaker Portal and reviewers logging in to a Reviewer Portal.

Shared attendee setup steps (Steps 1–6)

For attendees using forms, Mobile, the Speaker Portal, and the Reviewer Portal, the first six steps are the same. The remaining steps are explained under each use case heading below.

For all four uses, these six steps must be completed first.

1. System: Certain creates and sets up one or more “ATTENDEE LOGIN” SSOs for the system. Certain “System Master” users only.

2. Account: Enable SSO(s). An Administrator enables the “ATTENDEE LOGIN” SSOs for each account and sub-account in which they will be used. For an SSO to be available in a sub-account, the SSO must first be enabled in the parent account.

Go to and select the Enabled check box for the SSO(s) to be available. Edit the SSO configuration in the next two steps.

3. Account: Configure SSO field mappings. An Administrator maps IDP fields to Certain Fields.

> Note: In a sub-account, map these fields independently of the parent account because the mappings are not “inherited” from the parent account.

On , click for an enabled SSO and select the Certain Fields to map to the IDP Fields.

> Note: The Profile First Name and Profile Last Name in Certain must be mapped to the equivalent IDP fields. > Important: Do not map both to the same IDP field. > See the in that help topic.

4. Account: Customize SSO button (Optional).

An Administrator customizes the appearance of the SSO login button(s) for each SSO connection to be used on:

On , click for an enabled SSO and edit the Button... settings (color, text, icon, and class).

> Note: These button settings for an SSO Connection are used on all forms set to use that connection. > The same button settings are also used for Mobile, the Speaker Portal, and the Reviewer Portal if those are set to use the same connection. > You do not edit these settings further at those lower levels.

5. Event: An Administrator enables the Single Sign-On module for the event. In the event, go to and select the Single Sign-On Module under Functional Areas to be enabled for this event.

6. Event: An Administrator configures the SSO for an event. In the event, go to and select the Enabled check box for the SSO(s) to be available for use in the event. Selecting the check box makes the SSO available to the event’s forms, its Mobile web app, its Speaker Portal, and its Reviewer Portal.

> Note: You do not “edit” an SSO. > You select its check box in the list of SSOs.

In Forms

An “Attendee Login” SSO supports attendees registering on registration forms or logging back in to a form after having registered.

These are the remaining steps after 1–6 above. See especially step 4 about customizing the SSO button.

1. Form: An Event Builder selects the SSO(s) to be available on a form. In the event, go to to edit the Entry section for the form. Select the SSO(s) to be used.

2. Attendees: When an attendee is registering on that form, the attendee can click a button on the entry page (for example, LinkedIn or Facebook) to pre-populate details.

3. Attendees: Once an attendee has registered using an SSO, the attendee can log back in using the same SSO or their Username and Password. The attendee cannot use a different SSO.

Example: If the form offered the choice of LinkedIn and Facebook, and the attendee used LinkedIn to register, then the attendee could not use Facebook to log back in.

> Note: An attendee who registered without using an SSO connection cannot log back in to registration using an SSO connection. > The attendee can only log in using their Username and Password.

For a Certain Mobile HTML5 Web App

An “Attendee Login” SSO supports attendees logging in to a Certain Mobile web app.

These are the remaining steps after 1–6 above. See especially step 4 about customizing the SSO button.

1. Mobile: An Event Builder selects the SSO(s) to be available on the Login page of the Mobile web app. In the event, go to to edit the Login page. Select the SSO(s) to be used.

2. Attendees: When an attendee is logging in to the Certain Mobile web app, the attendee can click the same button on the page (for example, LinkedIn) to log in to Mobile using those credentials if the attendee registered using an SSO. The attendee can also log in with their Username and Password.

> Note: An attendee who registered without using an SSO connection cannot log in to the Mobile web app using one. > The attendee can only log in using their Username and Password.

For a Speaker Portal

A Speaker Portal use case is available only if these options are enabled for the event (in ):

These are the remaining steps after 1–6 above. See especially step 4 about customizing the SSO button.

1. Speaker Portal: An Event Builder selects the SSO(s) to be available on the Login page of the Speaker Portal. In the event, go to to edit the Login page. Select the SSO(s) to be used.

2. Speakers: When a speaker first registers in the Speaker Portal, the speaker can click a button on the Login page (for example, LinkedIn) to pre-populate details using those credentials.

3. Speakers: Once a speaker has registered using an SSO, the speaker can log in to the Speaker Portal using the same SSO or their Username and Password. The speaker cannot use a different SSO.

Example: If the Speaker Portal offered the choice of LinkedIn and Facebook, and the speaker used LinkedIn to register, then the speaker could not use Facebook to log in.

> Note: A speaker who registered without using an SSO connection cannot log in using one. > The speaker can only log in using their Username and Password.

For a Reviewer Portal

A Reviewer Portal use case is available only if these options are enabled for the event (in ):

These are the remaining steps after 1–6 above. See especially step 4 about customizing the SSO button.

1. Reviewer Portal: An Event Builder selects the SSO(s) to be available on the Login page of the Reviewer Portal. In the event, go to to edit the Login page. Select the SSO(s) to be used.

2. Reviewers: When a reviewer goes to the Reviewer Portal, the reviewer can click a button on the Login page (for example, LinkedIn) to pre-populate details using those credentials.

3. Reviewers: Once a reviewer has registered using an SSO, the reviewer can log in to the Reviewer Portal using the same SSO or their Username and Password. The reviewer cannot use a different SSO.

Example: If the Reviewer Portal offered the choice of LinkedIn and Facebook, and the reviewer used LinkedIn to register, then the reviewer could not use Facebook to log in.

> Note: A reviewer who registered without using an SSO connection cannot log in using one. > The reviewer can only log in using their Username and Password.

"Check-In App" SSOs

A “Check-In App” SSO supports Certain users logging in to the Certain Check-In app.

If Certain has configured a “CHECK-IN APP” SSO for a system, Check-In users can log in with their SSO credentials instead of their Certain username and password. Check-In users still need a record in Certain.

The workflow is simple:

1. Certain: Certain sets up a “CHECK-IN APP” SSO for the system. Certain “System Master” users only.

2. Account or Sub-Account: No configuration is required in an account or sub-account. If a “CHECK-IN APP” SSO is enabled for a system, it is automatically enabled for all accounts / sub-accounts.

3. Event: No configuration is required at the event level:

4. Check-In Users: When a Certain user logs in to Certain Check-In on their mobile device, the user can click the gear icon on the page to select the SSO and use those credentials to log in. The user can now use the app to check attendees in at an event just as if the user had logged in with their Certain username and password.

> Note: Only one CHECK-IN APP SSO can be activated for a system at any one time.