Fix (and completely revamp) the Shibboleth authentication module.

[drgrice1]

This updates the Shibboleth authentication module to fit into the new scheme of the general webwork2 authentication process. The module is set up to work just like all of the other up to date webwork2 authentication modules.

It has its own configuration file (conf/authen_shibboleth.conf.dist) that should be used instead of adding a buch of variables to localOverrides.conf. The include statement in localOverrides.conf should be uncommented, and the dist file copied and modified. Furthermore, relatively complete instructions on how to use the authentication module are in the comments in the configuration file.

The variables in the configuration file are all the same as before, except that there is one new one. That is the
$shibboleth{bypass_query}. Previously "bypassShib" was hard coded for this purpose. Now that can be configured. If that variable is not set (and for those using this module before it wouldn't be), then the bypass parameter will not work. So this is the only real change from before.

The issues that were causing webwork2's session not to work have been fixed. This means that proctored test access will work again.

The library browser, pg problem editor, and everything else that uses the rpc endpoints will work correctly. There simply is nothing special that the authentication module needs to do here, and most importantly it needs to not do anything special (like reverting to the base authentication module). The rpc enpoints now use the usual authentication methods, and that does work with mod_shib.

In order to achieve this without guess work like in #2608 I installed and configured a Shibboleth service provider that I could work with. That took quite a bit of effort.

[somiaj]

I can't test this directly, but don't notice any issues with a quick test of normal auth and simple use. I suggest we merge this for the shibboleth users (some of which have already tested this out and it works for)

[Alex-Jordan]

Should I just approve and merge this one and the hotfix?

[drgrice1]

Unless someone else wants to set up a Shibboleth test instance or find a way to test this more rigorously, we are probably going to need to just merge this. I asked @glarose to approve this pull request (or #2612), but he may not know how to review Github pull requests. In any case he gave approval via email (or at least stated that he had tested this and it worked to fix the issues he was experiencing).

[glarose]

Sorry for not following up about this sooner. I've pulled this to our production service, and it's working fine. I have a report that there may be some issues with RPC calls for courses that run through LTI on the same server, but haven't been able to confirm that. Currently, I'm seeing it working fine for all Shibboleth courses, and for at least some of the courses that we're running through LTI on the same server for our campus. I haven't heard back from the affected users who reported the issues.

[drgrice1]

If you are using the apache2 special configuration that I gave you that enables "lazy" configuration for the render_rpc and instructor_rpc endpoints, then that should also work for courses that use LTI authentication if the Shibboleth authentication module is omitted in the $authen{user_module} list for those courses (you will need to set that in the course.conf file for those courses).

If you are wanting some users to be able to authenticate with LTI and other users to be able to use Shibboleth in the same course, I am not sure that is entirely possible with the way that Shibboleth works. At least not while trying to allow Shibboleth to maintain the session at the same time.

[glarose]

If you are using the apache2 special configuration that I gave you that enables "lazy" configuration for the render_rpc and instructor_rpc endpoints, then that should also work for courses that use LTI authentication if the Shibboleth authentication module is omitted in the $authen{user_module} list for those courses (you will need to set that in the course.conf file for those courses).

This is the setting that I'm using, and it is working for the courses on my campus. We host LTI courses for another campus: I had one report of issues there, but haven't gotten confirmation of the error, nor been able to look at what it's doing yet. It's not out of the question that the issue resolved itself, but it's also possible that because it doesn't affect student use they are just working around it. I've asked for follow-up to figure out what is going on but haven't heard back.

[Alex-Jordan]

I will go ahead and merge these. It sounds like maybe there is a loose end that can be tied up later once there is more info about it.