25. Internationale ILIAS-Konferenz

Jetzt Tickets sichern / Order Tickets now!

Feature Wiki

Information about planned and released features

Tabs

Support for Deep Linking as Consumer/Platform

Page Overview

[Hide]

1 Initial Problem

ILIAS has exposed Deep Linking-related options for several releases, but these options do not currently provide a reliable end-to-end LTI 1.3 Deep Linking workflow. A user creating or configuring an LTI Consumer cannot reliably select content in the external Tool and have that selection returned as a usable LTI Consumer object in ILIAS.
ILIAS 11 needs a complete Platform/Consumer flow so that authorised users can select external LTI resources without manually copying target URLs and custom parameters.

2 Conceptual Summary

ILIAS 11 shall implement LTI Deep Linking 2.0 in the Platform/Consumer role.
When an authorised user creates or configures an LTI Consumer, ILIAS shall launch the configured external Tool in Deep Linking mode. The Tool shall provide its own content-selection interface. After the user selects one or more resources, the Tool shall return the selection to ILIAS. ILIAS shall create usable LTI Consumer repository objects following the current development approach: each returned LTI resource link becomes an LTI Consumer with the selected title, description, target URL and custom parameters.
The scope is limited to ILIAS as an LTI Consumer. ILIAS as an LTI Tool/Provider is not part of this proposal.

3 User Interface Modifications

3.1 List of Affected Views

  • Repository: Add New Object, LTI Consumer creation flow.
  • LTI Consumer: provider configuration/settings form.
  • Content Selection: embedded selection frame during creation and the Deep Linking modal launched from provider settings.
  • Repository: return page after selected content items have been created as LTI Consumer objects.
  • Administration: an informational message for global consumers, for which content selection is unavailable.

3.2 User Interface Details

  • When creating an LTI Consumer with a provider that supports Deep Linking, ILIAS displays a Content Selection step. The Tool is opened in an embedded frame after the LTI 1.3 login initiation and request exchange.
  • On the provider settings form, a Select button opens the Tool in a round-trip modal. Completing the selection closes the modal and returns the user to the repository location.
  • After the Tool returns one or more ltiResourceLink items, ILIAS creates one LTI Consumer object per item. The returned title and description are used as object properties; the target URL and custom parameters are stored for launch.
  • The Content Selection view provides a Cancel action. A cancelled or empty response must return control to ILIAS without creating content.
  • For consumers created in Administration, the Deep Linking action is replaced by the message: Consumers created in Administration do not allow content selection.

3.3 New User Interface Concepts

No new general UI concept is required. The implementation uses existing ILIAS components: standard buttons, a round-trip modal and an embedded iframe. The Tool owns the actual content-discovery and selection interface, as defined by the LTI Deep Linking specification.

3.4 Accessibility Implications

The ILIAS controls use existing, accessible UI components. The round-trip modal must manage focus correctly: focus enters the modal when opened, remains within it while active, and returns to the invoking Select button when closed. The embedded Tool user interface is supplied by a third party and remains the Tool provider's accessibility responsibility.
The feature must retain a keyboard-operable cancel/return path. The iframe requires a meaningful title and must not be the only means of obtaining status or returning to ILIAS. The post-selection result must be communicated through the normal ILIAS success or error messaging mechanisms.

4 Technical Information

The implementation is based on LTI 1.3, OpenID Connect login initiation and the LTI Deep Linking 2.0 message flow. ILIAS acts as the Platform/Consumer and the external application acts as the Tool.

  • ILIAS builds and signs an LtiDeepLinkingRequest JWT using RS256. It includes the Platform issuer, audience/client ID, deployment ID, user, context, roles, presentation target, return URL and deep_linking_settings.
  • The Tool is opened after the standard LTI 1.3 login flow. The request supports ltiResourceLink items, the presentation targets iframe, window and embed, multiple selections and automatic creation.
  • The Tool posts a signed LtiDeepLinkingResponse JWT to the configured return URL. ILIAS resolves the Tool key from its configured RSA key or JWK set, verifies the JWT signature and reads the returned content_items.
  • For each returned resource link, ILIAS creates an LTI Consumer repository object, assigns the selected provider, stores the target link URI and custom parameters, and derives metadata from the returned title and description.
  • The feature depends on the existing LTI Consumer component, repository object creation, ILIAS session handling, the PHP OpenSSL extension and the Firebase JWT library. No database schema change or general architectural change is required.
The feature extends the existing LTI Consumer component in ILIAS 11 and uses LTI 1.3, OpenID Connect login initiation and the LTI Deep Linking 2.0 message flow.
  • ILIAS shall act as the Platform and create a signed LtiDeepLinkingRequest for the configured Tool.
  • The request shall declare that ILIAS accepts ltiResourceLink items and shall include the configured return URL, deployment information and the context required by the Tool.
  • ILIAS shall process a signed LtiDeepLinkingResponse from the Tool and create one LTI Consumer repository object for every returned resource link, applying its title, description, target URL and custom parameters.
  • The flow shall reuse the existing LTI Consumer provider configuration, repository object creation, permission checks, session handling and JWT/key management.
No database schema change or general architectural change is expected. The implementation is limited to ILIAS as Platform/Consumer in ILIAS 11.

5 Privacy

The feature processes the data already required for an LTI 1.3 launch. The data is sent to the configured external Tool only where enabled by the existing LTI provider privacy settings and only for the purpose of completing the Deep Linking interaction.
  • Pseudonymous user identifier: identifies the user initiating the selection. ILIAS uses the email address when it is valid; otherwise it uses the configured privacy identifier.
  • Email address: sent as the primary contact address when a valid user email is available, or as the configured privacy identifier fallback. It enables the Tool to identify the user where required by the integration.
  • Name and profile picture: first name, family name, full name and profile picture are transmitted only according to the existing provider privacy configuration. They allow the Tool to display or identify the selecting user.
  • Roles and context data: the user role, context ID, context title and context type are sent to let the Tool apply the appropriate permissions and offer context-relevant content.
ILIAS stores the selected resource title, description, target URL and custom parameters as properties of the resulting LTI Consumer object. No additional personal data is stored specifically for Deep Linking.

6 Security

Yes. Deep Linking introduces an interaction in which ILIAS accepts a Tool-originating JWT and uses its content to create repository objects. The feature must follow the LTI 1.3 and LTI Deep Linking security model.

  • The Platform signs requests with its RSA private key using RS256. The Tool response must be verified against the configured Tool RSA public key or JWK set before any returned content item is processed.
  • The implementation must validate the response signature and the LTI message claims, including issuer, audience, deployment ID, message type, LTI version, expiry and nonce/state correlation. The return URL and the Tool redirect URIs must be restricted to configured, trusted values.
  • Returned target URLs, titles, descriptions and custom parameters are external input. They must be validated, encoded on output and handled under the normal ILIAS permission checks before objects are created.
  • Only users with permission to create LTI Consumer objects in the selected repository location may start or complete content selection.
  • The flow relies on HTTPS and the existing secure, HttpOnly, SameSite=None session-cookie handling for embedded cross-site LTI flows.

No new standalone public endpoint is required beyond the existing LTI 1.3 login and return handling.

7 Contact

Author of the Request: Díaz, Saúl [sdiaz]
Maintainer: Díaz, Saúl [sdiaz]
Implementation of the feature is done by: Díaz, Saúl [sdiaz]

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

No funding commitment has been recorded for this feature yet.
Interested institutions are invited to add their name and institution here.

9 Discussion

Please add discussion points, questions and Jour Fixe decisions here.

10 Implementation

Implemented for the LTI Consumer component in the ILIAS 11 development branch.

  • The OpenID Connect login handler recognises a Deep Linking request and restores the repository context for content selection.
  • ILIAS creates and auto-submits the signed LtiDeepLinkingRequest to the Tool after the login response.
  • The content-selection return handler decodes the Tool response using the configured Tool key and creates LTI Consumer repository objects from the returned ltiResourceLink content items.
  • Selected title, description, target URL and custom parameters are applied to each created object. The modal workflow closes and redirects the user back to the repository after completion.
  • Deep Linking is available from the repository creation flow and provider settings. It is intentionally unavailable for consumers created in Administration.

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

Formal TestRail test cases: pending.
Manual functional validation scenario:

{Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.

Full Screen

Last edited: Yesterday, 18:01, Falkenstein, Rob [rob]