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.

Component Interactions

SSP components shown here do not yet exist.

The "OAuth1 Services" component will be implemented using the SpringOAuth library. That library functions most naturally as a bean in a SpringSecurity FilterChain. But the diagram places them behind rather than in-front of the "LTI Launch API" on the assumption we require more detailed control over error responses. This may prove unnecessary or even unworkable once coding begins, in which case it may be necessary/desirable to reverse the relationship back to a more conventional architecture.

All SSP Platform/uPortal components 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

Not shown here: a OAuth nonce cleanup component. Unsure if SpringOAuth will provide that functionality OOTB.

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.

API Design

TBD TBD TBD (Lots more detail to add here)

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.)

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