...
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 | Yes | |
Log in using LearningBuilder password Same as above, but certain users are required to confirm a security code sent to their email address during every login. | 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. | No | This has been /wiki/spaces/LBDEV/pages/3191210296 but not implemented. Alternative is to use |
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. | Yes | As of 11.0.14 / 11.6.0, Sys Admins and other Roles (if configured) can bypass this redirect by directly accessing |
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 |
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. | 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 |
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 |
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. | Yes [11.0.14] | Sys Admins and other Roles (if configured) can still log in locally via |
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 |
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. | Yes [11.0.14] | Via permissions, some Roles can be allowed to log in locally while others are required to log in via SSO.
|
|
|