As a result of new requirements from LTI 1.3, D2L updated several areas of the Brightspace platform. With an entirely new process for deploying and managing learning tools, there are a few things you will want to learn to better support your instance.
Platforms now act like an OpenID Connect provider, communicating the user's identity to the tool using the OpenId login flow. The full authentication workflow comprises of an OIDC Launch, then a subsequent 1.3 Launch.
All LTI services are direct platform-to-tool communications and do not go through a browser. Tool-to-platform service requests are authenticated via a bearer token for access (OAuth2 client credentials grant code).
There are three main components of the LTI 1.3 security model:
- OIDC: An initial OpenID Connect (OIDC) launch occurs, wherein the tool is notified to an upcoming LTI launch and a third party-initiated login OIDC flow happens. This serves as a way to identify which user gets launched and helps ensure no launches are intercepted. D2L uses the LTI launch endpoint as the login URL.
- JSON Web Tokens: After the OIDC launch, we perform the 1.3 launch. When the launch payloads are constructed, they are signed as a JWT. All LTI messages are sent as JWTs, signed by the sender of the message. The receiver uses the public key, identified by KeyID, to verify the JWT signature. The receiver of this token can verify:
- Who sent it
- That the contents have not been altered
- OAuth2: To extend the services like Assignments & Grades, OAuth2 tokens are used to make subsequent service API calls, such as retrieving scores from the gradebook or syncing a new result.
Registration
Creating a new learning tool starts with an LTI Advantage administrator registering a new tool. Registering an LTI tool requires an administrator to either use the Dynamic Registration workflow (if available by the tool) or the manual workflow where the tool provides core details, such as the tool domain URL, tool redirect URL or keyset URL.
For any tool to create links, it needs to first be registered. Disabled registrations do not allow users to perform launches or use the tool. When setting up a new tool, D2L recommends that you disable it during setup. This allows administrators to create links and configure the tool fully before enabling it.
The required fields in the UI come directly from your tool. It is possible for tools to provide many redirect URLs. To add more, click + Add Redirect URL. The Domain URL is used in Brightspace to assist with domain matching, allowing Brightspace to suggest tools to bind ad-hoc links to during creation. You only need the Keyset URL if you use the extensions.
Substitution and custom parameters can be created at the registration level and cascade down to the deployment and link levels.
Once a tool is registered, you receive a Client Id, Brightspace Keyset URL, and a Brightspace OAuth2 Access Token URL to provide to the tool.
- Domain: Used for domain matching only (when creating new links through content to populate the dropdown).
- Redirect URLs: Redirect URLs which are end points where the authorization response can be sent to. This can be one or many values.
- OpenId Connect Login URL: The OpenId URL of the tool that is the location where the tool will launch to during the initial OIDC launch.
- Target Link URI: If a tool does not return a URL for the LTI link (ltiResourceLink) in the Deep Linking response, the target link URI is used as the URL. If neither are supplied, the domain in the LTI Registration is used.
- Keyset URL: The URL where the tool stores the keys. Used as a reference point when D2L performs a key lookup during the OIDC launch.
Dynamic Registration
Dynamic Registration is an LTI specification that allows for the automatic creation of a registration within a tool and platform, without the need to manually complete the registration. Dynamic Registration also supports the optional creation of the deployment and org level links within Brightspace.
Note: Dynamic Registration is publicly available for tools and platforms to implement and is in the Public Candidate Final stage of the standards development process.
The tool provides an endpoint URL to initiate the dynamic registration process; this endpoint must be https. When launching to the tool endpoint, D2L sends the tool a one-time use token that is given to the tool as part of the configuration URL; this token expires after 1 use or 1 hour, whichever comes first.
If deployment or links fail to be created, the registration process is still considered successful. The Dynamic Registration APIs return errors to the tool if there is a failure.
Out of scope: Registration updates
Registration level:
- Validation exists following existing registration validation rules
- URLs must be in HTTPS format
- Name and Domain must be unique across Org
- Keyset must be reachable