Overview

SSP will act as a LTI v1.0 Provider (TP). See the spec for what that entails, especially as it relates to Tool Consumers (TCs).

We choose 1.0 because we are leveraging LTI as an SSO spec with a standardized means for conveying the originating "learning context", i.e. course. We do not have any need for callbacks to the TC added in subsequent LTI versions. E.g. we do not need to pass back grades to the LMS. A future enhancement may leverage TC roster list callbacks, though, to support just-in-time provisioning of SSP Early Alert (EA) rosters.

Components

SSP components shown here do not yet exist.

The "OAuth1 Filter" component will be implemented using the SpringOAuth library. That library functions most naturally as a bean in a SpringSecurity FilterChain, so it is shown intercepting requests to the "LTI Launch API".  LTI only uses OAuth for request signature validation; there is no token exchange. So the "OAuth1 Filter" is only responsible for:

• Rejecting requests with invalid signatures, and
• Caching a SpringSecurity Authentication for requests with valid signatures.

OAuth1-validated Authentications will represent the TC, not the end user initiating the launch request.

SpringOAuth validates request signatures by looking up ConsumerDetails objects from a ConsumerDetailsService.  Our "LTI Services" will satisfy the latter interface.  See the org.jasig.ssp.service.security.oauth2.impl package for services playing similar roles in SSP's OAuth2 support, especially for mapping from a OAuth-specific *Details object to a UserDetails object required by SSP's internal security infrastructure.

All SSP Platform/uPortal components shown below do already exist, but special considerations exist for "SSO Ticket Service" and "Person Lookup Service":

• SSO Ticket Service - This is currently implemented as ISsoTicketDao / JpaSsoTicketDao but the former is not exposed to cross-context requests. It, or a "service-ified" version of it, will need to be added to the platform-java-api library. Registering the runtime service implementation with its interface can be something of a challenge, as can ClassLoader issues related to Hibernate/JPA. Please see the "Implementation" Section below for additional clarification.
• Person Lookup Service - This is currently implemented as IPersonLookupHelper / PersonLookupHelperImpl, which are not exposed to direct cross-context requests via platform-java-api, but adding a corresponding interface to that library should not be necessary since we can access equivalent functionality via a REST interface encapsulated by SSP's PersonAttributesService

This design relies on the Platform/uPortal SSO "ticketing" mechanism, which implements randomized, short-lived, one-time-use, "authenticated" URLs, because SSP currently relies on Platform/uPortal to establish end user sessions. But we choose not to factor the LTI launch URLs POSTed to by the TC into Platform/uPortal because we do not want to create long-term external dependencies on the /ssp-platform URL space. I.e. this approach will not create any new roadblocks to a standalone SSP deployment.

"LTI Services" is responsible for unpacking and handling all non-OAuth LTI request parameters and the SSP-specific {target} request path param. In particular, it is responsible for:

• Coordinating translation of the LTI user identifier to a SSP Platform account username. The LTI parameter used for this purpose will be configurable per-TC.
• Requesting new SSP Platform SSO "tickets" for authenticated LTI launch requests
• Mapping request parameters to SSP Platform portlet URLs

LTI launch to portlet URL mapping capabilities need not be particularly sophisticated/configurable at this time. See API Design below for more detail.

API Design

Live Launch Resource

Base URL: /ssp/api/1/lti/launch/live/

Method: POST

Parameters: None

Usage: For a launch request to a default view with no TC-specific path extensions. (Used by some TCs, e.g. Desire2Learn, to clarify the launching context and thereby control response content.)

Successful Response:

The effect of a successful launch is the creation of a new end user-redeemable ticket, i.e. authenticated session, so the response code is a 201 and a Location header encoding both the ticket identifier and the URL to which to redirect the end user if the ticket is redeemed successfully. {portlet-url} should evaluate to a portlet render request for whatever the default fragment is in the ticket-redeeming user's layout.

201 Created
Location: /ssp-platform/Login?upp_ticket={ticket-uuid}&refUrl={portlet-url}

Error Response:

OAuth signature validation response errors will be handled by SpringOAuth. This behavior may need to be customized depending on TC-specific UX requirements. It is known that a TP provider can pass IMS certification with SpringOAuth error messages alone, though.

Other errors will result in either:

• If the lti_launch_presentation_return_url LTI launch param is present: redirect to {lti_launch_presentation_return_url}?lti_errormsg={url-encoded-error-msg}
• If the lti_launch_presentation_return_url LTI launch param is not present: simple HTML page containing {url-encoded-error-msg}

url-encoded-error-msg is intended for end user consumption. As such it should be brief and only minimally technical. The underlying cause of the error should be logged in SSP via its standard logging mechanisms and associated with a unique identifier (random UUID is fine). The error identifier should be included in url-encoded-error-msg, should the user choose to follow up with her system administrator.

General categories of error worth communicating to the end user:

• End user account not on file
• Missing required parameter
• Unresolveable target tool
• Insufficient or incorrect credentials (i.e. bad signature, TC disabled, etc)
• System error

Base URL: /ssp/api/1/lti/launch/live/target/{target}

Method: POST

Parameters:

Usage: For a launch request to a specific view. Design note: the path param name is itself modeled as a path component to ensure fully disambiguated URLs in the future. E.g. some TCs append path components to clarify the launching context or navigational control that issued the launch request. This URL design ensures no clashes between the target path param and those TC-specific path extensions. I.e. to support such extensions, new API resources would be:

• /ssp/api/1/lti/launch/live/tcext/{tcext}
• /ssp/api/1/lti/launch/live/target/{target}/tcext/{tcext}

Response: TBD TBD TBD (need to figure out whether we want to return markup that redirects or just a 30x. it'll probably be markup, even if just to deal with cross-domain cookie issues when iframed.)

Test Launch Resource

Base URL: "Test" launch resources and supported methods are identical to "live" launch resources above, except that they are based in /ssp/api/1/lti/launch/test

Response:

TBD TBD TBD (potentially TC specific, esp for D2L)

Admin/Config

Admin/Config UX

TBD TBD TBD

Admin/Config API Design

TBD TBD TBD

Implementation

TBD TBD TBD