Search moodle.org's
Developer Documentation

See Release Notes

  • Bug fixes for general core bugs in 4.2.x will end 22 April 2024 (12 months).
  • Bug fixes for security issues in 4.2.x will end 7 October 2024 (18 months).
  • PHP version: minimum PHP 8.0.0 Note: minimum PHP version has increased since Moodle 4.1. PHP 8.1.x is supported too.
/auth/lti/ -> auth.php (source)

[Source view]

Differences Between: [Versions 310 and 402] [Versions 311 and 402] [Versions 39 and 402] [Versions 402 and 403]

(no description)

File Size: 457 lines (22 kb)
Included or required:0 times
Referenced: 1 time
Includes or requires: 0 files

Defines 1 class

auth_plugin_lti:: (11 methods):
  __construct()
  user_login()
  complete_login()
  find_or_create_user_from_membership()
  find_or_create_user_from_launch()
  create_user_binding()
  get_user_binding()
  is_valid_provisioning_mode()
  create_new_account()
  update_user_account()
  update_user_picture()


Class: auth_plugin_lti  - X-Ref

LTI Authentication plugin.

__construct()   X-Ref
Constructor.


user_login($username, $password)   X-Ref
Users can not log in via the traditional login form.

param: string $username The username
param: string $password The password
return: bool Authentication success or failure

complete_login(array $launchdata, moodle_url $returnurl, int $provisioningmode,array $legacyconsumersecrets = [])   X-Ref
Authenticate the user based on the unique {iss, sub} tuple present in the OIDC JWT.

This method ensures a Moodle user account has been found or is created, that the user is linked to the relevant
LTI Advantage credentials (iss, sub) and that the user account is logged in.

Launch code can therefore rely on this method to get a session before doing things like calling require_login().

This method supports two workflows:
1. Automatic account provisioning - where the complete_login() call will ALWAYS create/find a user and return to
calling code directly. No user interaction is required.

2. Manual account provisioning - where the complete_login() call will redirect ONLY ONCE to a login page,
where the user can decide whether to use an automatically provisioned account, or bind an existing user account.
When the decision has been made, the relevant account is bound and the user is redirected back to $returnurl.
Once an account has been bound via this selection process, subsequent calls to complete_login() will return to
calling code directly. Any calling code must provide its $returnurl to support the return from the account
selection process and must also take care to cache any JWT data appropriately, since the return will not inlude
that information.

Which workflow is chosen depends on the roles present in the JWT.
For teachers/admins, manual provisioning will take place. These user type are likely to have existing accounts.
For learners, automatic provisioning will take place.

Migration of legacy users is supported, however, only for the Learner role (automatic provisioning). Admins and
teachers are likely to have existing accounts and we want them to be able to select and bind these, rather than
binding an automatically provisioned legacy account which doesn't represent their real user account.

The JWT data must be verified elsewhere. The code here assumes its integrity/authenticity.

param: array $launchdata the JWT data provided in the link launch.
param: moodle_url $returnurl the local URL to return to if authentication workflows are required.
param: int $provisioningmode the desired account provisioning mode, which controls the auth flow for unbound users.
param: array $legacyconsumersecrets an array of secrets used by the legacy consumer if a migration claim exists.

find_or_create_user_from_membership(array $member, string $iss,string $legacyconsumerkey = '')   X-Ref
Get a Moodle user account for the LTI user based on the user details returned by a NRPS 2 membership call.

This method expects a single member structure, in array format, as defined here:
See: https://www.imsglobal.org/spec/lti-nrps/v2p0#membership-container-media-type.

This method supports migration of user accounts used in legacy launches, provided the legacy consumerkey corresponding to
to the legacy consumer is provided. Calling code will have verified the migration claim during initial launches and should
have the consumer key mapped to the deployment, ready to pass in.

param: array $member the member data, in array format.
param: string $iss the issuer to which the member relates.
param: string $legacyconsumerkey optional consumer key mapped to the deployment to facilitate user migration.
return: stdClass a Moodle user record.

find_or_create_user_from_launch(array $launchdata, bool $syncpicture = false,array $legacyconsumersecrets = [])   X-Ref
Get a Moodle user account for the LTI user corresponding to the user defined in a link launch.

This method supports migration of user accounts used in legacy launches, provided the legacy consumer secrets corresponding
to the legacy consumer are provided. If calling code wishes migration to be role-specific, it should check roles accordingly
itself and pass relevant data in - as auth_plugin_lti::complete_login() does.

param: array $launchdata all data in the decoded JWT including iss and sub.
param: bool $syncpicture whether to sync the user's picture with the picture sent in the launch.
param: array $legacyconsumersecrets all secrets found for the legacy consumer, facilitating user migration.
return: stdClass the Moodle user who is mapped to the platform user identified in the JWT data.

create_user_binding(string $iss, string $sub, int $userid)   X-Ref
Create a binding between the LTI user, as identified by {iss, sub} tuple and the user id.

param: string $iss the issuer URL identifying the platform to which to user belongs.
param: string $sub the sub string identifying the user on the platform.
param: int $userid the id of the Moodle user account to bind.

get_user_binding(string $issuer, string $sub)   X-Ref
Gets the id of the linked Moodle user account for an LTI user, or null if not found.

param: string $issuer the issuer to which the user belongs.
param: string $sub the sub string identifying the user on the issuer.
return: int|null the id of the corresponding Moodle user record, or null if not found.

is_valid_provisioning_mode(int $mode)   X-Ref
Check whether a provisioning mode is valid or not.

param: int $mode the mode
return: bool true if valid for use, false otherwise.

create_new_account(array $userdata, string $iss)   X-Ref
Create a new user account based on the user data either in the launch JWT or from a membership call.

param: array $userdata the user data coming from either a launch or membership service call.
param: string $iss the issuer to which the user belongs.
return: stdClass a complete Moodle user record.

update_user_account(stdClass $user, array $userdata, string $iss)   X-Ref
Update the personal fields of the user account, based on data present in either a launch of member sync call.

param: stdClass $user the Moodle user account to update.
param: array $userdata the user data coming from either a launch or membership service call.
param: string $iss the issuer to which the user belongs.

update_user_picture(int $userid, string $url)   X-Ref
Update the user's picture with the image stored at $url.

param: int $userid the id of the user to update.
param: string $url the string URL where the new image can be found.