Case 1: Enterprise Centralized Learning Hub – ALM as LTI Provider to Canvas

Introduction

A global enterprise uses Adobe Learning Manager (ALM) as its central corporate learning platform while regional universities and partners use Canvas. The organization wants employees and partners accessing Canvas to seamlessly launch ALM compliance and certification courses without separate logins. In this case, ALM acts as the LTI 1.3 Tool Provider and Canvas acts as the LTI Consumer (Platform).

Business Objective

• Deliver compliance training hosted in ALM to users inside Canvas.
• Maintain centralized reporting in ALM.
• Automatically provision users.
• Synchronize grades back to Canvas gradebook.

Architecture Overview

When ALM acts as the Provider, Canvas sends a secure LTI launch request to ALM. The flow includes:

1. OIDC Login Initiation URL
   This URL starts the OpenID Connect authentication handshake. Canvas redirects the learner’s browser to ALM using this URL.

2. Redirect (Launch) URL
   After authentication, ALM receives a signed ID Token at this endpoint containing user identity and course context.

3. JWKS URL
   ALM publishes a JSON Web Key Set endpoint. Canvas uses this public key to verify the digital signature of tokens.

4. Client ID and Deployment ID
   Client ID identifies Canvas as a registered platform.
   Deployment ID distinguishes separate integrations (e.g., Production vs Staging).

Step-by-Step Configuration

In ALM:
1. Enable LTI Integration.
2. Register Canvas as a Platform.
3. Capture Issuer URL from Canvas.
4. Store Client ID and Deployment ID.
5. Provide ALM’s JWKS URL to Canvas.

In Canvas:
1. Create Developer Key (LTI 1.3).
2. Enter ALM’s Initiate Login URL.
3. Provide ALM’s Redirect URL.
4. Activate and deploy the tool.

User Data Flow

When a learner clicks the ALM course inside Canvas:
• Canvas sends an ID Token (JWT).
• Token includes:
  - sub (unique user ID)
  - email
  - given_name
  - family_name
  - roles
  - context (course information)

If the user does not exist in ALM:
• ALM auto-creates the user profile.
• Role mapping occurs (Instructor, Learner).

Grade Data Flow

Using LTI Advantage Assignment and Grade Services (AGS):
• ALM sends grades back to Canvas via the AGS endpoint.
• Canvas provides a Line Item endpoint during setup.
• ALM posts score with user ID and score value.
• Canvas updates gradebook.

Security

• All tokens signed using RS256.
• Token validated using JWKS.
• Expiry timestamp checked to prevent replay attacks.

Outcome

Central compliance courses remain managed in ALM while Canvas users experience seamless integration with synchronized grades and automatic user provisioning.
 

Case 2: University Extension Program – ALM as Consumer Showing Moodle Content

Introduction

A university runs executive programs in ALM but maintains legacy courses in Moodle. They want ALM authors to embed Moodle-hosted courses as modules inside ALM’s learning path. Here ALM acts as LTI Consumer and Moodle acts as Provider.

Business Goal

• Use ALM as front-end learning hub.
• Launch Moodle content inside ALM Player.
• Maintain Moodle content control.
• Avoid duplicate content migration.

Configuration Overview

In this case:

ALM requires:
• Tool URL (Moodle Launch URL)
• OIDC Login URL (from Moodle)
• Public Keyset URL (JWKS)
• Client ID issued by Moodle
• Deployment ID

What Each URL Does

OIDC Login URL:
ALM redirects learner to Moodle to initiate secure authentication.

Tool/Launch URL:
After authentication, Moodle launches the requested course back into ALM’s iframe player.

JWKS URL:
Allows ALM to verify Moodle’s signed JWT tokens.

User and Context Exchange

When ALM launches Moodle:
• ALM sends user claims:
  - user_id
  - name
  - email
  - role
• Moodle validates token signature.
• If user doesn’t exist in Moodle:
  - Moodle auto-provisions account.

Course Context

ALM passes:
• Course ID
• Module ID
• Custom parameters (optional)

Grade Synchronization

If enabled:
• Moodle sends grades back via AGS endpoint.
• ALM receives score and updates learner transcript.

Data Security

• Tokens encrypted and signed.
• Audience claim ensures token is intended for Moodle.
• Nonce prevents replay.

Outcome

ALM becomes unified learning experience while Moodle content remains reusable. Learners access everything through ALM player.
 

Case 3: Multi-LMS Corporate Ecosystem – ALM as Both Provider and Consumer

Introduction

A multinational corporation uses ALM for employee development, Blackboard for academic partnerships, and D2L for certification programs. They require bi-directional integration.

Scenario 1: ALM as Provider to Blackboard

Blackboard registers ALM using:
• Client ID
• Issuer URL
• JWKS endpoint
• Redirect URI

Launch Flow:
1. User clicks ALM course inside Blackboard.
2. Blackboard sends ID token.
3. ALM validates signature.
4. Course launches.

Scenario 2: ALM as Consumer of D2L

ALM registers D2L tool.
• Launch URL
• OIDC login endpoint
• Public Keyset URL

User Provisioning

If user exists in Blackboard but not in ALM:
• ALM creates new user upon launch.
If user exists in ALM but not in D2L:
• D2L provisions automatically.

Grade Flow

ALM to Blackboard:
• POST score via AGS.
D2L to ALM:
• D2L pushes grades via line item endpoint.

Security Settings Exchange

Both platforms exchange:
• Issuer ID
• Client ID
• Public Keys
• Authorization endpoint

Each validates:
• iss claim
• aud claim
• exp timestamp

Outcome

A federated learning ecosystem where platforms interoperate securely without duplicating user databases.
 

Case 4: External Partner Training Portal – Controlled Access with Auto-Provisioning

Introduction

A manufacturing company trains distributors via ALM. Distributors use their own LMS (Brightspace). ALM must provide certification courses securely.

Use Case

ALM is Tool Provider.

Brightspace sends:
• id_token (JWT)
• role = Learner
• organization ID (custom claim)

If distributor employee not in ALM:
• ALM auto-creates user.
• Assigns to partner group.
• Enrolls in certification course.

URL Breakdown

Issuer URL:
Identifies Brightspace tenant.

Authorization Endpoint:
Used during token exchange.

Access Token URL:
Used for AGS grade reporting.

JWKS URL:
Validates signature.

Grade Reporting

After assessment:
• ALM sends POST request to Brightspace grade endpoint.
• Includes:
  - scoreGiven
  - scoreMaximum
  - activityProgress

Security Controls

• HTTPS mandatory.
• Key rotation supported.
• Separate deployment IDs per partner.

Outcome

Secure partner onboarding without manual account creation.
 

Case 5: Content Marketplace Model – ALM Authors Display Third-Party LMS Courses

Introduction

A training provider offers premium content hosted on various LMS platforms. ALM authors want to curate external LMS courses inside ALM learning paths.

ALM as Consumer

Steps:
1. Create LTI module.
2. Enter Launch URL.
3. Configure OIDC Login URL.
4. Enter Client ID.
5. Store JWKS URL.

Launch Behavior

When learner clicks module:
• ALM sends signed JWT.
• External LMS validates using ALM public key.
• Course displays inside ALM player iframe.

Settings Exchange

During registration both platforms exchange:
• Platform ID
• Public key set
• Redirect URIs
• Token endpoint

User Data Flow

Claims sent:
• sub (unique ID)
• email
• name
• roles
• context ID

If user missing in provider LMS:
• Account auto-created.

Grade Return

Provider LMS calls ALM AGS endpoint.
ALM stores grade in transcript.

Data Governance

• Only minimum required user data shared.
• FERPA/GDPR compliance maintained.
• Role-based access mapping enforced.

Outcome

ALM becomes curated marketplace hub while leveraging distributed LMS content providers securely and seamlessly.