...

NB: Dynamic account provisioning as a side-effect of TC launch requests is out of scope, as is dynamic EA roster provisioning, whether based on data in the TC launch requests themselves or LTI callback services offered by the TC.TODO TODO TODO: Class model for TCs

Because SSP requires a Person be associated with the current Authentication when processing any given request, we will most likely follow the pattern established by previous work on OAuth2 support and implement our new TC entity model as a subclass of Person. This unfortunately widens that table even further, but is much easier than refactoring to an Account-Person distinction as described in https://github.com/Jasig/SSP/commit/e7af8330e0aa2da452da84819c25895f444387a2

Please note that because we need access to original secrets in order to verify OAuth signatures, TC secrets will need to be persisted in plain text (unlike OAuth2 secrets, which are salted and hashed before storage).

SSP Platform Components

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

...

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.TODO TODO TODO: Figure out how this actually works, if it can work at all

SSO Ticket Service - Implementation Status

This component presented several technical challenges, so as part of authoring this design doc, we verified that the proposed approach will actually work. There is now a new shared API that exposes SSO ticket issuing capabilities to non-portlet requests: SsoTicketService. For additional detail on the technical challenges, please see 

Person Lookup Service

The "Person Lookup Service" component shown on the diagram 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

...

{
    "result_code": <string>,   // Should be either 'OK' or 'FAILURE'
    "result_description": <string>|null
}

D2L's specifications do not explicitly require a response MIME type. The implementation should start by using SSP's standard JSON response MIME type.

...

Admin/Config UX

Admin/Config API Design

TBD TBD TBD

Testing

Expect that this will be a standard SSP admin UI-driving CRUD API, so not going to detail it all out here. See OAuth2ClientController, which should be able to act as a high-fidelity template for a TC consumer API. For the base resource, I propose /ssp/api/1/lti/tc.

Testing

Pearson teams report success using the following link, but it appears to be broken or behind a paywall now:

http://www.imsglobal.org/developers/LTI/test/v1p1/lms.php

Instead, either install a local Moodle or Sakai instance or try Dr Chuck's PHP test harness in GitHub:

https://github.com/csev/sakai-lti-test

Especially:

https://github.com/csev/sakai-lti-test/blob/master/index.php