25. Internationale ILIAS-Konferenz

Jetzt Tickets sichern / Order Tickets now!

Feature Wiki

Information about planned and released features

Tabs

Names and Role Provisioning Services (NRPS)

Page Overview

[Hide]

If you need any help in filling out this wiki page, please have a look at the page ’How To Suggest A New Feature’. And please complete the metadata information in the right column after having created the page.

1 Initial Problem

ILIAS does not provide complete LTI Names and Role Provisioning Services (NRPS) 2.0. External LTI Tools cannot retrieve the members and roles of an ILIAS course when ILIAS is the Platform, and ILIAS cannot retrieve the roster of an external Platform when it is the Tool.
NRPS support in both roles is needed for interoperable LTI Advantage integrations and for the path towards LTI Advantage certification in ILIAS 12.

2 Conceptual Summary

ILIAS 12 shall implement NRPS 2.0 in both LTI roles.
  • Platform: ILIAS shall advertise a protected, read-only NRPS context-membership service to authorised LTI 1.3 Tools.
  • Tool: ILIAS shall request the NRPS scope, read the NRPS launch claim and retrieve the roster from an external Platform when enabled for that integration.
  • Privacy: each provider integration shall control whether name and email are shared. The standard minimum of pseudonymous identifier, roles and context identifier is always available.
NRPS is enabled per LTI provider integration. Integrations that do not request or receive NRPS continue to work without roster access.

3 User Interface Modifications

3.1 List of Affected Views

  • LTI Provider administration: provider configuration form.
  • LTI Consumer administration: consumer/provider configuration form.
  • LTI 1.3 registration and provider configuration review, where offered scopes and services are shown.

3.2 User Interface Details

  • The LTI 1.3 provider configuration form shall contain a checkbox labelled Enable Names and Role Provisioning Services (NRPS). When selected, ILIAS grants the configured Tool access to the NRPS service for launches using this provider.
  • The form shall use the existing privacy controls for Name and Email. These controls determine whether those attributes are included in the roster; no new privacy control is introduced.
  • The LTI Consumer configuration shall show whether the external Platform offers NRPS and, when it does, request the contextmembership.readonly scope. The service is used only when NRPS is enabled for that integration.
  • Existing Save and Cancel buttons retain their standard behaviour. A validation message is shown if an NRPS-enabled integration lacks the configuration required for the LTI 1.3 service.

3.3 New User Interface Concepts

No new UI concept is required. The feature uses existing configuration forms, checkboxes, validation messages and privacy settings.

3.4 Accessibility Implications

No new accessibility issue is expected. The configuration uses existing ILIAS form controls and labels. Provider configuration must remain fully keyboard-operable and validation messages must be announced through the standard ILIAS message mechanisms.

4 Additional Information

4.1 Involved Authorities

Authority to Sign off on Conceptual Changes: Díaz, Saúl [sdiaz]
Authority to Sign off Code Changes: Díaz, Saúl [sdiaz]

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

The implementation shall follow NRPS 2.0 and LTI 1.3.
  • As Platform, ILIAS shall include the namesroleservice claim with context_memberships_url and service version 2.0 in eligible launches, and expose a GET endpoint returning application/vnd.ims.lti-nrps.v2.membershipcontainer+json.
  • As Tool, ILIAS shall obtain an access token with scope https://purl.imsglobal.org/spec/lti-nrps/scope/contextmembership.readonly and call the URL supplied in the launch claim.
  • The Platform endpoint shall support pagination. Role filtering and membership differences are optional extensions and are not required for the initial scope.
  • The feature depends on the LTI 1.3 authentication, JWT, key, access-token and provider privacy services. It is planned for ILIAS 12 and does not require a new repository object type.

4.3 Privacy

NRPS processes course membership data.
  • Pseudonymous user identifier: identifies each membership and corresponds to the LTI launch subject.
  • Roles: identifies the member role in the course context, for example Learner or Instructor.
  • Context identifier: identifies the course or group whose roster is requested.
  • Name and email: are optional attributes and are disclosed only if permitted by the existing LTI provider privacy configuration for the integration.
As Tool, ILIAS processes the equivalent data received from the external Platform only for the enabled integration and its authorised workflow. The feature does not require persistent storage of a roster beyond existing LTI configuration and audit requirements.

4.4 Security

Yes. NRPS exposes or consumes protected membership data.
  • The Platform endpoint is read-only and must require a valid LTI 1.3 access token with the NRPS readonly scope. The token must be bound to the registered Tool and the relevant deployment.
  • The endpoint must validate authorisation, context and launch/deployment relationship before returning any membership data. A Tool must only access the roster of the context for which it is authorised.
  • Membership responses and all optional attributes must respect the configured LTI privacy settings. Input from an external Platform, including service URLs and roster responses, must be treated as untrusted and validated before use.
  • HTTPS and the existing LTI 1.3 JWT and access-token security mechanisms are required.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers: Díaz, Saúl [sdiaz]

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

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

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.

Full Screen

Last edited: 24. Jul 2026, 13:32, Díaz, Saúl [sdiaz]