In a previous post, I described how I made my Sample LTI Consumer website (Consumer) into an SLC–now inBloom—application:
The first step was to extend the OAuth 2.0 support in ASP.NET MVC 4.5 to work with inBloom.
When my sample Consumer is launched from the inBloom Sandbox, OAuth 2 and the Sandbox identity provider (SAML) are used to authenticate and authorize a user in my sample Consumer.
Once there, the user can import inBloom course sections and gradebook entries (each inBloom Section becomes a Consumer course and each GradebookEntry becomes an assignment). And new assignments are written back to inBloom as new gradebook entries.
So far, none of this uses LTI. This post describes how I make use of LTI after the Consumer is launched.
LTI 1.1 has three main tricks:
- Authentication – It uses 2-legged OAuth in each request so the provider can infer authentication based on evidence from the consumer
- Authorization – It includes context name/value pairs in each request so the provider can authorize the request and provide the appropriate services and content
- Outcomes – A well defined scheme exists so the Provider can send outcomes back to the Consumer
My sample Consumer (now a registered inBloom application) makes use of all 3 LTI tricks. First of all every assignment in my sample Consumer is a link. If the assignment includes LTI credentials (key and secret), then when the assignment is launched, it is launched with an LTI request which includes both Authentication and Authorization fields so the Provider can authenticate and authorize the request. The values that are sent to the Provider came from inBloom.
If the Provider sends an outcome back to the Consumer using the LTI Outcomes service, the Consumer will send the outcome back to inBloom as a StudentGradebookEntry using the inBloom REST API.
Why Not Use OAuth 2 and the inBloom API instead of LTI?
Because the two organizations are optimizing for different goals, their solutions are optimized to solve different problems. inBloom is optimizing their solution (the inBloom Data Store) to collect data (including assignment grades) that will improve personalized learning. IMS is optimizing their solution (LTI) to a single, simple scheme to launch tools and content, and collect outcomes. This is similar to internet access: inBloom is focusing on the infrastructure and IMS is focusing on the last mile problem.
Show Me Some Code
As you saw in a previous post, when the Consumer application is launched from the inBloom sandbox, the Consumer will request an accessToken from inBloom’s authorization service. Once the Consumer receives the accessToken, it pairs the inBloom user to a local account, creating one if necessary. This was all handled using the built in support for external logins that comes with the MVC 4 Internet Application template in Visual Studio.
Launching an assignment with LTI for an inBloom user is no different than launching an assignment with LTI for any other user in the Consumer website. See Building the LTI POST.
Sending the outcome (also known as grade or score) back to inBloom is new. Keep in mind that in the LTI model, the provider can send an outcome back to the consumer at any time…not necessarily immediately after completing the assignment. For example, there may be a manual grading process that takes days to complete. To keep track of where to send the outcome, my Sample LTI Provider (Provider) creates an Outcome record for each unique lis_result_sourcedid,
Later, when the Provider needs to send an outcome back to the consumer, it retrieves the Outcome record and POSTS the score,
When the Consumer receives the score, it records it locally,
And then attempts to forward the score to inBloom,
See that highlighted line?
var token = GetLongLivedSessionToken(score.TenantId);
All of the inBloom API calls I described at the top of this post (import course sections, etc) use the accessToken of the current user. But scores can arrive from the provider at any time…even days after the user has logged off. We need an accessToken that is valid even if the user is long gone. That is what the inBloom long-lived session token resolves. It is a special accessToken that inBloom will create that does not expire (or it expires after a VERY long time).
Summary
inBloom is building the infrastructure to improve personalized learning. LTI solves the “last mile” problem of using learning tools in the classroom. Together, they make a great team.
Learning Tools 