LTI 1.3 in Action

LTI 1.3 in Action


Hi and welcome to the second video in
our getting to know LTI Advantage video series. In this video we’re going to show
you a demo of LTI Advantage in action with LMSs like Blackboard, Canvas
and Sakai and then we’ll cover some key concepts and step through key messages
that get sent back and forth during the LTI launch flow. If you’d like an
introduction to LTI Advantage please have a look at the first video here. To show us the demo and walk through the LTI launch flow I’d like to introduce my
colleague Diego del Blanco. Diego is a developer here at Unicon and has
worked on several of the early implementations of LTI Advantage for our
customers. He also helped to review the LTI documentation and certification test
suite for the IMS LTI workgroup. Over to you Diego. Thanks, Linda. So let me show
you how LTI 1.3 works in a real environment. LTI 1.3 provides
an enhanced security framework that includes the OpenID Connect
authentication process. For this demo we built a tool here at Unicon that uses
core LTI 1.3 with OIDC and we connected it to several different
learning management system platforms. The platforms we are going to show it running on today are Canvas, Blackboard and Sakai. This is a LTI 1.3 tool that has
been configured and is running in a Canvas instance. The connected tool is a
demo tool that we designed to stop during the OIDC authentication process and
show the messages exchanged between the platform and the tool. Of course in a
real tool all this process is transparent to the user and it appears
to happen in only one step. When we click on the link the first step is the OIDC
process. As said, the demo tool stops at this point to show the parameters that
the platform has sent to the demo tool. We will talk in detail about these
parameters in future videos and the OIDC requests that the demo tool has prepared
in response. We can send the OIDC request back to the platform by clicking on the link. The platform receives the OIDC request
from the demo tool and after validating it returns the complete LTILinkResourceRequest. The demo tool shows what was inside the request. For example the roles or information about the context. With all this information a real
tool can check the authorization for the user and if it is correct the requested
resource is displayed, and if not, then an error message is generated. Now we are
going to view the same tool, the demo tool, being launched from Blackboard
with LTI 1.3. We have configured it as a course tool so it appears in the left
menu. Once we click on it we have the same process as before. We start with
the OIDC authentication and after that we will see all the information that the
tool receives from the platform and everything is exactly the same. We’re
viewing the authorization that is going to be sent. We click on the button and we have all the information there. Everything is the same parameters but
provided by Blackboard as we can see. And here we have the same
process but in Sakai. We launch the demo from the left menu. We display the OIDC request. We return the OIDC request answer to the platform and the
platform displays and returns all the request with everything that we are
displaying in this screen. This demonstrates how the same tool can be integrated perfectly in three different LMSs with LTI. Of course that’s the reason why we are using LTI. Now let’s go a little deeper to talk
about important concepts when establishing a connection and then we will walk through the messaging flow. In a platform we can deploy an LTI tool
in different ways. As administrators we can deploy different tools and give access to those tools from all the LMSs. In practice, most LMSs
allow instructors to deploy tools too. That means that maybe, the same tool is
deployed several times in the same LMS and of course a tool can be deployed in
different LMSs. So how do the tools and platform keep track of which is which when it comes to the different deployment scenarios? In LTI 1.3 there are 3 identifiers which will allow us to deal with this. The issuer, we have the
issuer that will identify the platform. For example it could be lms.unicon.edu or Blackboard or Canvas or Sakai or Moodle or anything that
identifies the platform. The client_id will provide a unique identifier for the
tool inside the platform and the deployment_id will be assigned uniquely
by the platform to each one of the different deployments of the same tool. That means that this combination; issuer, client_id, and deployment_id must be unique and it must allow the tool and the platforms to differentiate between
each deployment. To initiate the launch LTI 1.3 core includes a basic
message called LTIResourceLinkRequest. It is used to launch a tool resource from
a platform. The workflow to make this happen will have some steps. Authentication to be sure that everyone involved is really who they are saying and then we will send the request content (the user, the roles, the resource link) so the
tool can authorize the final display of the resource. Let’s see that in a diagram. In this workflow we can see the platform, the tool, and the user agent, that is the
browser. The browser usually will just redirect the request and keep some session values. All this process starts with a user that wants something from the platform. The user clicks in a link and then the platform prepares our first message
called OIDC login request. This message will contain some information that will be returned later to the platform so the platform can remember about this request. The tool receives this message and looks to see if the issuer exists. If it is a
valid issuer then it generates an OIDC authentication request. On that request, the tool returns the information that will be used by the platform to remember
and will add its own 2 attributes to later validate the answer from the
platform. The nonce and the state. This will be in the request together with
other interesting things, such as the client_id. The nonce will be
used to avoid replication of the same request because it’s valid only one
time and the state is an open attribute to send any information that the tool considers interesting to be returned by the platform in the request. For example, it can include information signed with the tool private key so later only
the tool can check the signature and be sure that everything is OK. Once this
message is generated the tool sends the authentication request to the platform. The platform receives the request and checks the content, finds those attributes
that the platform remembers and if everything is OK the platform generates
a big JWT token, where it includes all the information about the LTIResourceLinkRequest, and the nonce sent by the tool and everything is signed with the
platform’s private key. this JWT is called id_token and
is sent again in a POST together with the original state that was generated by
the tool here at this point. The tool receives now the state that can be used
to be compared with the state in the session and can have useful information
inside and then it uses the public key of the platform to check the signature. It checks the nonce (that is inside the JWT) to be sure that this has not been used before and once the full authentication
is finished and everything is checked the tool is going to read the user
information, the roles, the resource link, show the request and validate the
authorization. If the user has permissions to access to
the linked resource then the tool is going to display it in the browser. With this, the workflow ends and the tool is off and running inside the platform. So, I hope this has given to you a good sense of what the
interaction looks like when initiating a connection between a platform and a tool
using LTI 1.3. Next videos and next steps are going to be using the LTI
Advantage services but this is the prerequisite to do that. Stay tuned
for our next video, where we will go into more detail showing the actual messages transmitted between the platform and the tool. Please feel free to contact us at
Unicon if you’d like to talk to us more about the project and to see how we can
help you. Thank you very much.

You May Also Like

About the Author: Oren Garnes

Leave a Reply

Your email address will not be published. Required fields are marked *