Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents

Local login scenarios

Use case

Currently supported?

Notes

Log in using LearningBuilder password

This is the default approach in which all user data is stored in the LearningBuilder database and users log in with a password managed in LearningBuilder

(tick) Yes

Log in using LearningBuilder password
+ email-based security code

Same as above, but certain users are required to confirm a security code sent to their email address during every login.

(tick) Yes

Introduced in 11.0.14 / 11.6.0.

Can be enabled for specific Roles only/

Log in using TOTP Authenticator app (e.g. Microsoft Authenticator)

Uses a 3rd party application on a mobile device to provide additional security.

(error) No

This has been /wiki/spaces/LBDEV/pages/3191210296 but not implemented.

Alternative is to use

SAML SSO with an identity provider

a 3rd party Identity Provider that provides the authenticator support.

Legacy single-sign-on scenarios

See Single Sign-On (SSO) for details on the legacy LearningBuilder SSO integration. This is being slowly phased out in favor of SAML Identity ManagementProviders.

Use case

Currently supported?

Notes

Redirect all users to 3rd party login screen

All unauthenticated users are redirected to a 3rd party login screen specified in App Config.

The 3rd party authenticates them and redirects back to LearningBuilder passing a signed access token.

(tick) Yes

As of 11.0.14 / 11.6.0, Sys Admins and other Roles (if configured) can bypass this redirect by directly accessing /Account/LoginSpecial

SAML / OIDC based single-sign-on

LearningBuilder can use SAML Identity ManagementProviders to integrate with 3rd parties without the need for any custom integration coding or engineering support.

Note

As of 11.0.14 / 11.0.6, LearningBuilder only supports a single SAML Identity Provider. Support for multiple concurrent Identity Providers is planned for a future release.

Use case

Currently supported?

Notes

Redirect all users to 3rd party login screen

All unauthenticated users are redirected to a 3rd party login screen specified in App Config.

The 3rd party authenticates them and performs an IdP-initiated

SAML

authentication flow.

This works best when the 3rd party login screen shares branding with LearningBuilder, so the user is not surprised by the automatic redirect.

(tick) Yes [11.0.14]

As of 11.0.14 / 11.6.0, Sys Admins and other Roles (if configured) can bypass this redirect by directly accessing /Account/LoginSpecial

Manual SAML initiation

In this approach unauthenticated users land on the LearningBuilder login page, but there is no login form. Instead, there is a button that says “Log in with <provider>” that begins a SP-initiated

SAML

authentication flow.

This can be used when the 3rd party login screen does NOT share branding with LearningBuilder, and where users might be confused by an automatic redirect. Requiring the user to click a button to begin the process removes the confusion about why they are seeing the 3rd party screen.

(tick) Yes [11.0.14]

Sys Admins and other Roles (if configured) can still log in locally via /Account/LoginSpecial

Local login form + SAML / OIDC button

Unauthenticated users land on the LearningBuilder login page that displays both a local login form and a button to begin SSO via SAML

SSO

or OIDC providers.

This is useful when local passwords are still desired, but where there is a trusted 3rd party that can be used as a secondary way to authenticate.

(tick) Yes [11.0.14]

Via permissions, some Roles can be allowed to log in locally while others are required to log in via SSO.

Note

Currently supports a single

SAML provider

Identity Provider only.

Support for multiple

SAML providers

concurrent Identity Providers is planned for a future release.