SSO in a multi-tenant instance

Owned by Seth Petry-Johnson
Last updated: Jan 07, 2022
1 min read

See also: https://heuristicsolutions.atlassian.net/wiki/pages/resumedraft.action?draftId=521502769

Overview

The use of multi-tenancy in LearningBuilder can complicate Single Sign-On scenarios, and not all possible scenarios are currently supported.

Scenario

Notes

Scenario

Notes

  • SSO into MT LearningBuilder instance

  • All tenants use the same SSO provider

Supported as 1st class feature

In this approach, users navigate to the hostname for the Tenant they wish to access. They are redirected to the centralized SSO provider, which is notified of the requested Tenant.

The SSO provider authenticates them, authorizes access to the requested Tenant, and the redirects.

Requires that users navigate to the Tenant they are trying to access.

Allowing users to navigate to the default tenant, and then be redirected to an arbitrary Tenant as a result of the SSO process, may require extra effort.

  • SSO into MT LearningBuilder instance

  • Tenants use different SSO providers

Supported via custom integration / may require innovation

In this approach, each Tenant is associated with a different identity provider. The SAML support added in 11.0.0 can support multiple providers, but is not designed to vary them by tenant.

Supporting this scenario might be possible with a custom AWS Lambda in the middle of the SSO process, or it might require additional innovation.

  • SSO into 3rd party system, using credentials from a MT LearningBuilder instance

Not supported

In this approach, access to a 3rd party system would require having credentials for a specific Tenant.

LearningBuilder’s SAML identity provider does not currently support any business rules that would allow it to validate credentials against a specific Tenant.