Installation

Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Spencer Felsted -
Number of replies: 10

I'm working on building an updated WW server and have run into a couple of issues.

1) Course Selection within Canvas is not showing the Context ID (See photo 1a below)

I don't see anything that is obviously wrong, and while debug_lti_parameters is enabled, there are no relevant logs in webworks2.log

At this point, I have not been able to map the LTI parameters, so I'm not sure if that is related.

2) Shibboleth Auth is successfully working within Apache and the provider, but WW is not thinking it is signed in.

I believe this issue is within the Apache RequestHeader set field and the user_id mapping, but I'm having difficulty diagnosing where the disconnect is.

If I have my Shibboleth attribute ID set to "userprincipalname" and my $shibboleth{mapping}{user_id} set to "upn". How does my Apache config need to look?


Any help would be appreciated!

Attachment Issue 1a.png
In reply to Spencer Felsted

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Danny Glin -

By default each external authentication module that you enable is set to be the only one that is active, so if you want both LTI and Shibboleth authentication you will need to tell WeBWorK that both should be checked.

In localOverrides.conf you will need to add the following somewhere after the LTI and Shibboleth authentication sections:

$authen{user_module} = [

        'WeBWorK::Authen::LTIAdvantage',

        'WeBWorK::Authen::Shibboleth',

        'WeBWorK::Authen::Basic_TheLastOption'

];

At the very least this should get you some debug information about LTI in the logs.

I don't know much about Shibboleth authentication in WeBWorK, but reading the documentation in the config file it says that you should replace every instance of "uid" in the apache config block with whatever you set $shibboleth{mapping}{user_id} to, so in your case that would be "upn".  Also, if I understand Shibboleth authentication correctly you will need to use lazy Shibboleth authentication in order to allow LTI to connect directly to WeBWorK before falling back to Shibboleth.

In reply to Danny Glin

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Spencer Felsted -

1)

I already have the $authen{user_module} set as you specified in localOverrides.conf.

I have also tried both of these modules individually (by commenting out 'WeBWorK::Authen::*' in '$authen{user_module}' and 'include("conf/authen_*.conf");' in localoverrides.conf)

Alas, still no LTI logs.

2)

I originally had everything set to eppn and had the Shibboleth, Apache, and Webwork configs set accordingly, including replacing all the uid instances, but it wasn't working. So I have now set the names to what we would prefer them to be, and am asking for assistance with how it should be set.

I already have it set to lazy auth as well, so that it should work with the LTI.

2.5)

Sidenote: When I go to a course login, I have not been able to get it to try external auth when I have external_auth=0, it just goes directly to the internal auth page.

Instead, I have been manually going to https://webwork.yourschool.edu/Shibboleth.sso/Login and then also to the variant with the return to variable in order to test. Not sure if this is related or not.


Thank you for your input. I feel like I've been pretty thorough reading through the docs and confs, but here I am.

In reply to Spencer Felsted

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Danny Glin -

Based on what you're describing it doesn't sound like either of the external authentication modules (LTI or Shibboleth) are being invoked.  One thing to try is putting the '$authen{user_module}' variable in the course.conf file for a single course.  That is loaded after all of the site-wide config files, so if that variable is being overwritten somewhere else in the config this should take precedence.

On the LTI side, I just want to confirm that you are creating an LTI link in Canvas and not just a regular HTML link.  If that is the case then you should see some LTI-related stuff in the logs.

In reply to Danny Glin

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Spencer Felsted -

Okay, after some further testing, it is sending me to Shibboleth on all course login attempts without any changes. I believe I forgot to clear my SSO token before I started testing last time, and didn't see the quick redirect. I have not been able to see it send to LTI for auth, but I'm not sure how exactly that should look. Sorry for the misdirection this caused.

Correct, it is an LTI link within Canvas, but no LTI logs. It is set up with a Developer Key in Canvas that has the Course Selection and Assignment Selection components assigned and configured as described in the LTI 1.3 doc. I am not the Canvas Admin, but I have gotten assurances from them that the Canvas side is set up correctly.

In reply to Spencer Felsted

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Spencer Felsted -

Following up to clarify that both auth methods are still not working.

1) The authenticated SSO user is not being handed back to Webwork.

2) LTI 1.3 is enabled and configured with debug enabled, yet no logs related to the LTI are present.

In reply to Spencer Felsted

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Danny Glin -
At least for LTI authentication it sounds like there is not actually an LTI request making it through.  This means that most likely either Canvas is not sending an LTI request, or WeBWorK is not configured to receive it.

Have you tried manually creating an LTI link to a WeBWorK course in Canvas rather than using the content selection tool?  If this still doesn't work, then I'd say try what I previously suggested with enabling LTI authentication for a single course.
In reply to Danny Glin

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Spencer Felsted -
I had not tried manual yet, but here is my current test with no results:

- Manually created links with both of these formats:
-> https://webwork.yourschool.edu/webwork2/coursename
-> https://webwork.yourschool.edu/webwork2/coursename/assignmentname
- $authen{user_module} in localOverrides as the last variable set (after the includes for the authen_ configs)
- $authen{user_module} also copied to the end of a course config in my test course

When using manually created links for my test course, it opens WebWork (https://webwork.utahtech.edu/webwork2/ltiadvantage/login) and shows the internal sign-in page with no additional entries in the log.
In reply to Spencer Felsted

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Spencer Felsted -

As I have not heard back, I have continued to troubleshoot this, albeit with no luck.

Due to the Fall semester approaching quickly, I decided to shift back to Canvas LTI 1.1 and LDAP. This is a combination we have successfully deployed on WebWork 2.15.

With LTI 1.1, I have successfully gotten the Context ID to appear. Upon putting this into WebWork and retrying the course selection, I get sent to the login screen. With debugging enabled, I am getting all the proper information from Canvas in the browser console. I have set both the primary and fallback fields to match fields I am receiving, with still no luck.

With LDAP, Webwork is not initiating any traffic to the LDAP server, nor can I find any evidence in the logs that it has tried. This has been tried with LDAP and LDAPS, over DNS and direct IP. This is not a firewall issue. I feel very confident about this troubleshooting.

All together, I have tried LTI 1.1, LTI 1.3, LDAP, and Shibboleth with no success.

Attached is proof that the only instances of the authen definitions that are active are in defaults and localoverrides (excluding .dist files). This was searching for uncommented definitions in the entire /opt/webwork directory.

As always, any assistance would be much appreciated.

Attachment Screenshot_20250804_122636.png
In reply to Spencer Felsted

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Danny Glin -
A few thoughts that might help with troubleshooting.
On the LTI 1.3 front:
  • Just confirming that when you tried manually creating links that they were LTI links and not plain web links. If you were sent to the ltiadvantage URL then this is almost certainly the case.
  • Make sure that your LTI links are set to open in a new window.
  • Have you tried a different browser?  The content selection tool requires access to third party cookies in order to open inside a window (iframe) within your LMS.  Chrome is particularly bad about not allowing this even if you try to change the settings.

On the LDAP front:

  • What do you see in the course login.log?  If the LDAP module is being invoked then it should log any failed attempts to authenticate with the LDAP server.
  • You can enable debugging for your WeBWorK server in the conf/webwork2.mojolicious.conf file.  With debugging enabled there will be a debug log entry every time the LDAP module is called, so this will tell you if it's actually being invoked.
In reply to Danny Glin

Re: Ubuntu 24.04 + WW 2.19 + Apache + Canvas LTI 1.3 + Shibboleth Issues

by Spencer Felsted -

I didn't receive an email from your message. Is that due to the forum migration, possibly?

Good news though, I rebuilt the server with Ubuntu 24.04 + WW 2.20 + Apache and here is the current state of things:

LDAP: Working fully
Canvas LTI 1.1: Working fully
Canvas LTI 1.3: Same symptoms as before, but this was only a quick test.
Shibbolith: Untested

To answer your previous questions, I was being sent to ".../ltiadvantage/login", so I believe the links were proper. I think I tried both iframe and new window, but I can't say for certain. Firefox on Linux is where most of the testing has taken place, but I have tested in Firefox (Linux), Chromium (Linux), Firefox (Windows), Chrome (Windows). All of the testing in this paragraph was done on the previous install.

Due to the beginning of the semester starting next week, we are electing to keep this in its current state until the next semester break (late December). I will likely test some of these in a sandbox to see if I can work out any of these kinks before the break.