Connecting IMS LTI and SAML (Draft)

© Copyright 2012 IMS Global Learning ConsortiumAll Rights Reserved.

1

Charles Severance, Ph.D.IMS Global Learning Consortium (IMS

GLC)

http://www.imsglobal.org/http://www.dr-chuck.com/

IMS LTI and SAML / SSODRAFT - 01


2

Thanks to

• Keith Hazelton, University of Wisconsin

• Scott Fullerton, University of Wisconsin


3

Problem Statement

• We need a way to align IMS Learning Tools

Interoperability and (SAML)


4

Use Cases

• When a LMS is protected using an SSO and

launches an external tool using LTI, we to

communicate the SSO identity to the external tool

• This enables the external tool to connect the

user_id value from LTI with an SSO identity

• This allows the user to connect directly to the

external tool and log in using their SSO


5

Scenario

• We have three LMS's at three schools, one

protected using SAML, one protected using

CAS, and one that has no SSO

• They all connect to an external tool that is

capable of LTI, CAS, and SAML and has

relationships with the appropriate SAMLE IDP

and CAS Server


6

saml.edusaml.edu cas.educas.edumod_samlmod_saml mod_casmod_cas

nada.edunada.edu

hyperlti.comhyperlti.com

mod_casmod_casmod_samlmod_saml /launch/launch

saml.edu

IDP

saml.edu

IDP

cas.eduServercas.eduServer

Scenario


7

Essential Design Concept

• The LTI Launch is completely normal

providing the normal within-LMS data like

user_id, role, context_id, etc.

• If the LMS is protected using an SSO and the

current user is logged in through the SSO, we

add the type of SSO (SAML, CAS, etc) and the

identity provider for the SSO.


8

Essential Design Concept (cont)

• The LTI launch does *not* include the SSO

identity as there is no way to do this reliably.


9

Design For External Tool

• The external tool has an unprotected LTI

launch URL to receive LTI requests (/launch)

• The external tool has SSO-protected URLs for

all the identity providers and SSO types it

has a relationship with (/cas_edu, /saml_edu)


10

Design for External Tool

• If the LTI launch code receives a launch with an SSO

type and Identity provider that it is capable of

handling, it sets up the LTI data (user, course, role,

etc) in the session and forwards to the appropriate

SSO-protected url on its own server

• Since the user is already signed on via the SSO, they

simply fall through with REMOTE_USER properly set


11

Design for External Tool

• Under the SSO-protected URL, the code

knows the LTI user course, and role as well

as the Identity provider and enterprise

identity.

• The tool can link all of these together within

its data structures.


12

External Tool Design

• From that point forward, the tool can identify

the user either via an LTI launch through

user_id or through a direct login to an SSO-

protected URL that provides REMOTE_USER


13

hyperlti.comhyperlti.commod_samlmod_saml

/launch/launch

saml.edu

IDP

saml.edu

IDP

lms.saml.edulms.saml.edumod_samlmod_samlBrowser

Browser

(1) User accesses LMS, (2) redirected to SSO, (3) SSO displays login page.

11

22

33


14


/launch/launch

saml.edu

IDP

saml.edu

IDP


Browser

(1) User enters login submits to IDP, (2) IDP sets cookie and redirects to LMS, (3) LMS displays screen

11

22

33

saml_cookie

saml_cookie


15


/launch/launch

saml.edu

IDP

saml.edu

IDP


Browser

(1) User selects LTI tool. (2) LMS sends signed LTI data form to browser (3) browser submits data to LTI launch url

11

22

user_id=12sso_type=samlsso_idp=saml.edu

saml_cookie

saml_cookie

33


16


/launch/launch

saml.edu

IDP

saml.edu

IDP


Browser

(1) Tool stores the LTI launch data in a session for the browser and then (2) redirects to the mod_saml URL

22


saml_cookie

saml_cookie

11


17


/launch/launch

saml.edu

IDP

saml.edu

IDP


Browser

(4) The user's browser follows the redirect, adding the SAML cookie, (5) the mod passes the request through setting SAML identity

22


saml_cookie

saml_cookie

11

remote_user=csev44

55


18


/launch/launch

saml.edu

IDP

saml.edu

IDP


Browser

(6)The mod requests and receives an attribute from the IDP and (7) adds it to the user data


saml_cookie

saml_cookie

66

remote_user=csevphone=763-0300

77


19


/launch/launch

saml.edu

IDP

saml.edu

IDP


Browser

User has new browser. (1) Access the tool directly at SSO-protected URL. (2) mod redirects to IDP, (3) IDP produces login page 11

22

33


20


/launch/launch

saml.edu

IDP

saml.edu

IDP


Browser

(1) User enters login submits to IDP, (2) IDP sets cookie and redirects to tool. (3) Tool looks up user data based on SAML id

11

22

saml_cookie

saml_cookie


remote_user=csevphone=763-0300

33


21

Notes

• This extends easily to multiple types of SSO

providers and multiple identity providers per

SSO.

• This carefully avoids the LMS forwarding the

SSO identity, but instead provides a

mechanism for the tool to "add" the SSO

identity to a session through a redirect


22

Questions / Comments

• This is a draft – comments welcome

Connecting IMS LTI and SAML (Draft)

Technology

saml copyright

saml launch sso

saml lms

saml mod

sso copyright

saml cookie

saml url user

saml sso draft