...

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.

The implementation will validate oauth_timestamp freshness, and the acceptable slippage must be configurable via the SSP config UI. This can be a global config, i.e. not per-TC. SpringOAuth's OOTB nonce validation capabilities do not support nonce uniqueness validation, either in memory or against a persistent store, and thus cannot be used as-is. Depending on available development time, a uniqueness-validating in-memory implementation (with its implicit limitations) is acceptable, but a database-backed implementation is strongly preferable. Reference implementations of the latter are likely available to expedite development.

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

...

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. See additional considerations below for /test resources.

Other errors will result in either:

...

• End user account not on file
• Missing required parameter
• Unresolveable Unresolvable 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}

...

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}

An empty target param value should be handled as if the target path component were not present at all.

In the future, target values might be further qualified, likely with dot notation, e.g. 

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

ea.roster or ea.form or ssp.journal, but doing at this writing would be of minimal value, because of limitations in LTI and SSP.

Response:

Same as for /ssp/api/1/lti/launch/live described above.

Implementation note: See SsoController for examples of building refUrl values, esp when targeting the Early Alert portlet.

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

This capability is being added specifically for the D2L TC, which specifies that the response status code should always be 200, and the response payload should be JSON:

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

result_description is intended for a technical audience and can contain a more detailed explanation of the problem if result_code is FAILURE. Still, complete detail should be confined to SSP logs, and result_description should include an identifier for the error instance for further investigation.

The implementation needn't include elaborate mechanisms for configuring other TC-specific launch test response protocols, but please keep in mind that the protocol discussed here is D2L-specific. Thus the implementation should be sure to remain as encapsulated as possible.

The most challenging aspect of the implementation will likely involve intercepting error responses from SpringOAuth. At this writing it is unclear whether this can be dealt with effectively via configuration or if custom code will need to be added to the filter stack. Obviously the former is desirable, but the latter may prove necessary.

Admin/Config

Admin/Config UX

...