Identity Providers

This is implemented in Sys Admin → Identity Management

See also: https://heuristicsolutions.atlassian.net/wiki/spaces/DOCS/pages/3360096518

Overview

It is often desirable for users to sign into one system (the Service Provider [SP]) using credentials they have for another system (the Identity Provider [IdP]).

LearningBuilder can play either role:

  • LB as Service Provider: Users log into LearningBuilder using 3rd party credentials, and data from the 3rd party system are used to update Workflow Attributes

  • LB as Identity Provider: Users log into 3rd party using LearningBuilder credentials, and Workflow Attributes can be sent to the 3rd party

Supported protocols

LearningBuilder supports the following identity protocols:

Protocol

LB as SP?

LB as IdP?

Can trigger demo sync when LB is SP?

Protocol

LB as SP?

LB as IdP?

Can trigger demo sync when LB is SP?

OpenID Connect (OIDC)

SAML 2.0

LearningBuilder as a Service Provider

As of 11.0.14 / 11.6.0, LearningBuilder only supports integration with a single Identity Provider. Adding support for multiple Identity Providers is planned for a later release.

https://heuristicsolutions.atlassian.net/wiki/spaces/LBDEV/pages/3347873922

LearningBuilder clients often manage their user data in a separate Member Management System (MMS). SSO allows those users to access LearningBuilder with their MMS credentials so that they do not need a LearningBuilder-specific password.

For this to work, there must be some unique identifier (often email) that is the same in both systems.

When an unauthenticated user accesses LearningBuilder, they are redirected to a 3rd party system to authenticate. After they authenticate, they are sent back to LearningBuilder with a token containing “claims” that provide the user identity and other supporting data.

Once LearningBuilder validates the token, the user is considered “signed in” to the LearningBuilder account with the matching identifier.

If a matching user account does not already exist, one is created automatically and assigned a specified Role.

Supporting claims can provide basic demographic data such as name, email, phone, etc.

For more complex demographic data, the SSO process can be configured to trigger LearningBuilder’s “Demographic Synchronization” service.

Process flow for SSO against an external Identity Provider

Login page options

When configuring an Identity Provider, a Sys Admin can indicate whether or not a button should be displayed on the Login page.

When configured, these will appear beneath the login form.

Including IdP buttons on the login page

LearningBuilder does not currently support “branded” buttons, but these buttons can be targeted with custom CSS for custom styling.

Using the /LoginSpecial page

In some cases, the Identity Provider SSO is only used for specific Roles, and you may not want to show the IdP login buttons to all users because it could confuse them.

The /LoginSpecial page was designed for that scenario. It provides a secondary login screen that displays all IdP login buttons, even those that are hidden from the primary login page.

This page also has dedicated Content Blocks for additional messaging.

LearningBuilder as an Identity Provider

Many exam integrations involve redirecting the user to the exam provider’s system for scheduling.

Just like above, this requires that there be some unique identifier (often email) that is the same in both systems.

In this case, LearningBuilder acts as the “Identity Provider” and uses SAML to securely identify the user to the exam provider. The exam provider then uses the shared identifier to look up (or create) its own user account for that person and then considers them “signed in” to its own system.

All user accounts participating in the SSO process must have a configurable Role in LearningBuilder.