I am working at integrating OOD with a LTI (https://www.imsglobal.org/basic-overview-how-lti-works) launcher from Canvas in order to provide a SSO experience to students enrolled in selected courses in our University.
The problem I am facing is that the LTI launch is essentially just a post from a verifiable referer . So even if I can essentially trust the launch as if it was a proper authentication step, it cannot be presented to apache2 as an authentication.
The approach I am taking is to process the request at a specific location in the virtual host and, after validating the request, user creation and all other steps I need to take care of, create a session with the mod_session module, that I am planning to use to grant authorization at all other locations where the actual content is proxied ( /pun , /node , …) .
I was trying to use LuaAuthzProvider to validate the session and grant access.
However unfortunately that tap into the mod_authz_core, which processes the request before mod_session.
Has anyone tried to do something similar?
Do you have any recommendation or alternative approach to suggest?
For example would you recommend to leave sessions alone and use a token based authorization? e.g. jwt?
Hi! Thanks for posting and I’m sorry for the delayed response. We’ve never heard of LTI or canvas before, so we didn’t quite know what to say.
That said, I would say that token based auth like open id connect (OIDC) works very well. We use keycloak at OSC with a lot of success. I’ve even got google oidc authentication to work. So if you’re able to use OIDC, I would recommend it because the mod_auth_openidc works well.
Also, I’ve asked the same question on Canvas’ support site because apparently OSU uses canvas too, so I already had an account to do so. It seems like this could be a very powerful integration with open on demand, so I took the liberty of initiating that question with them.
Thanks for the question and the heads up on that platform!
thanks for your response.
I actually have made some progresses in my integration with LTI.
I am now successfully processing the request that comes from Canvas ( in my case at /lti/launch), validating and accepting the request and provision accounts on the fly. I then create a session token that I then process with a LuaAuthzProvider hook to grant (or deny) access to the other resources ( /pun , … etc ) . I solved my problem with sessions and authorization modules. I am still using mod_session to create and encrypt the cookie when the user comes from Canvas to OOD, but later instead of relying on mod_session in apache to decrypt I have simply implemented the token decryption step myself directly in the Lua code, so I can use it even though apache still has not engaged the session management module.
The advantage that we see using LTI rather than simply using for example OIDC against the central shibboleth ( or cas or keycloak) is that with the LTI post I get a lot of additional information, including the specific class the students are working on. That has advantages for accounting and managing access to resources, and allows me to potentially present customized environment tailored to the specific class.
The only problem I have at the moment is that I cannot at any given time verify if the user is still authenticated in Canvas. The LTI launch protocol does not have anything to support that (… as far as I understand , … I am new to that as well). So I am simply expiring the session frequently and send back the user to canvas to recreate a new session. This is certainly an acceptable solution for now but not a great user experience. I will evaluate if I can move to a jwt based model and use Canvas as auth server in that model, although I am not sure if that is supported by LTI.
In any case, I need to cleanup and refactor my code but once I am done with that I will be more than happy to share my work with you. Maybe it could be useful also to your institution, or if you are interested we can work together to make it better and more robust.
Awesome! Glad to hear you’ve made progress. If you open source your code we’ll definitively be interested! I’m sure this won’t be the last time we want to integrate with Canvas through LTI, which is to say that it would likely be very useful.
Thanks again for the topic!
I’m solving this topic now (you solved it yourself), but we’re still interested in your solution. Indeed, nobody has answered my question on the canvas support site (or a moderator hasn’t approved it?).
But in either case, I would definitely encourage you either with us or the larger world because, surprisingly, canvas doesn’t seem to have an integration with apache.
sorry I disappeared for a while from this conversation.
Just circling back and adding a couple of extra notes here as an update. In case anyone is interested please feel free to reach out. We are currently cleaning up and packaging the code, and I’ll be happy to share it with anyone interested.
As discussed in a previous post, the way we ended up implementing that is using a verification of the oauth1 signature from the LTI post and using the attributes sent by canvas to map to a username.
In our case we also added procedures to create the linux users on the fly the first time students login, in a separate directory federated with our central directory. But that is due to particular need we had of managing the class accounts differently than the regular research accounts, so probably not so much of general interest.
We have successfully used OOD integrated with Canvas in the Spring20 semester for a few courses who were willing to test the service. Things worked out pretty well, and we are now working at improving some aspects of the service, monitoring, etc, as the plan is to go to full production service for about 15-20 courses in the Fall20.