​
LMS Integration Types

​
Tenant-Specific Integration

In this type of integration, content is pushed to a single LMS customer (tenant), and we have access to user-specific context. This allows us to match users based on their unique identifiers (SSO IDs). For each user in the LMS system, we can track progress and completions. In this case, the user syncing flow is crucial for retrieving the user ID to handle completions properly. The SSO ID provided by the LMS will be the key identifier to link users to the content and their progress.

​
Content Distribution Integration

In this type of integration, a single StackOne linked account pushes content to an LMS, which then makes that content available to multiple customers. We do not have access to the specific user context or individual users associated with each piece of content in the LMS. As a result, we do not have direct access to the user IDs. In these cases, we typically rely on the SSO ID used in the previous request or pass through a random user ID if specific user context is unavailable.

​
Unified User Syncing Flow

​
General Flow for Both Integrations

Regardless of the type of LMS integration, the user syncing flow follows these basic steps:
  1. Sync Users: List /users
  2. Handle Responses:
    • If the request succeeds (with a valid user list), proceed with matching users to their respective content or completions.
    • If the response returns a 501 Not Implemented error, it means that the integration is a content distribution type, and we don’t have direct access to user context.

​
Handling Different Scenarios Based on LMS Type

  • For Tenant-Specific Integrations:
    • After retrieving the list of users, you will be able to match users by their SSO ID or email address to the user metadata received from the unified request.
  • For Content Distribution Integrations:
    • Since we don’t have access to user context, the SSO ID from the previous request (if available) should be passed straight in as the user ID for tracking. However, if no user context is available:
      • Pass a Random User ID: This ensures that the request can proceed without failing due to a lack of user context.
      • Pass Query Params as a Passthrough: For integrations like Cornerstone, information will be provided in the query parameters. In this case, pass a random user ID and the entire query parameters as passthrough values to ensure the correct processing.

​
Handling Cornerstone Integration

  • For Cornerstone LMS integrations, the SSO ID or user ID will be provided in the query parameters.
  • When this occurs, a random value can be used as the user ID, but all the query parameters should be passed along as passthrough values, as they might contain other essential details needed for the request.

​
Error Handling and Return Codes

  • 501 Not Implemented:
    • If the request returns a 501 Not Implemented response, it indicates that the integration is of the content distribution type. In this case, user context is not available, and we proceed with a workaround (such as passing a random user ID or using the SSO ID as the user ID).
  • Missing User Context:
    • If no user context is provided (for content distribution integrations), passing a random user ID should allow the request to proceed, though tracking individual user completions will be less precise.
    • For Cornerstone, the entire query parameters should be passed through as passthrough values.

​
Flow Diagram

​
SAML/SSO Authentication Flows

Understanding how users authenticate with your application through different LMS platforms is crucial for implementing robust user syncing and provisioning strategies.

​
LMS SAML/SSO Support Scenarios

Scenario 1: LMS Supports SAML 2.0 SSO Integration When an LMS platform supports SAML 2.0:
  • The LMS acts as the Identity Provider (IdP)
  • Users click on content within the LMS and are seamlessly redirected to your application
  • Users are automatically authenticated via SAML SSO
  • Your application receives an SSO ID for user identification
  • This provides the smoothest user experience with single sign-on
Scenario 2: LMS Doesn’t Support SAML/SSO When an LMS platform lacks SAML/SSO capabilities:
  • Users must authenticate directly with your application
  • Alternative authentication methods are required:
    1. Standard email and password authentication
    2. Social login through Google and Microsoft
  • Deep links may still land users on your application’s login page
  • Additional user provisioning strategies become essential

​
Unified User Provisioning Strategy

To ensure reliable user identification across any LMS platform regardless of SAML/SSO support: User Provisioning Approach:
  • Provision users in your system with comprehensive identity data
  • Support multiple authentication flows simultaneously
  • Store all required identifiers for matching (SSO ID, email, external references)
  • Implement fallback authentication when SAML isn’t available
Authentication Methods to Support:
  1. Email + password (universal fallback)
  2. Google/Microsoft social login (optional but recommended)
  3. SAML 2.0 SSO (when LMS supports it)
Benefits of This Approach:
  • Consistency: Same user provisioning flow works across all LMS platforms
  • Flexibility: Supports both SSO and non-SSO authentication scenarios
  • Reliability: Users can always authenticate, regardless of LMS configuration
  • Future-proof: Easy to add new authentication methods as needed

​
Authentication Flow Diagram

​
Practical Examples and Use Cases

​
Example 1: Tenant-Specific LMS Integration (SSO ID usage)

​
User Identification

To ensure reliable user matching between your system and the LMS, we provide multiple identification points:
  • LMS system ID
  • Email address
  • User name
  • Additional system-specific identifiers (returned as external_reference)
Filtering
  • We support email filtering when natively supported by the LMS.
  • Currently, email filtering is supported on GO1.
Recommended Sync Process
  • Initial Setup:
    • Store the StackOne ID for each matched user in your database.
    • This ID is essential for creating assignments, recording completions, and maintaining user relationships.
  • Ongoing Maintenance:
    • Implement a regular synchronization process:
      • Fetch current user data from /lms/users endpoint.
      • Compare against your local user database.
      • Update local records with any changes.
      • Store new StackOne IDs for newly matched users.
    • This approach ensures consistent user identification and data accuracy.

​
Example 2: Content Distribution LMS Integration (Random User ID)

For a content distribution LMS integration, since we do not have access to user context, we:
  1. Pass the SSO ID from the previous request as the user ID if available.
  2. If the SSO ID is not available, generate a random user ID and pass it in the request.
  3. For Cornerstone integrations, pass a random user ID and include all query parameters as passthrough values.