Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 

Jira Legacy
serverJASIG Issue Tracker
serverId76221f40-4501-3df1-8578-6c87908cbdf7
keySSP-2470
. For additional detail on SsoTicketService design a and usage, see 
Jira Legacy
serverJASIG Issue Tracker
serverId76221f40-4501-3df1-8578-6c87908cbdf7
keySSP-2461
.

...

No Format
{
    "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.

...

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