LTI User mapping doesn't work since 4.4

Steps to reproduce

Steps to reproduce:
1. Configure Opencast as an LTI tool provider.
2. Remove the fourth constructor argument from the LtiLaunchAuthenticationHandler in etc/security/mh_default_org.xml.
3. Send an LTI request with "ext_user_username" set to the name of an existing Opencast user.

Actual Results:
You are not authenticated as that user.

Expected Results:
You should be authenticated as that user.

Workaround (if any):
Add a fourth constructor argument, e.g. like this:


Tim Schroeder
August 6, 2018, 8:41 PM

Issue is fixed. I attached a patch.

P.S.: I noticed this also affects 3.6, but I can't edit the issue description anymore.

Tim Schroeder
August 6, 2018, 9:36 PM

I don't know if it's even necessary to test this. You should be able to see what's wrong by just looking at the change that introduced this bug:

Karen Dolan
September 6, 2018, 5:06 AM

@timschroeder, my assumption is that the reason the 3 parameter method was made impotent was to prevent the admin-to-admin vulnerability. If this was infact the case, that 3 param method should have been removed altogether to force the 4 param call.

Your pull allows sites to streamline by ignoring the vulnerability by avoiding the 4th param with the exception cases. The aternative would have been to force adopters to send an empty set in the 4th param (via that updated etc/security/mh_default_org.xml) to manually permit admin-to-admin super powers between systems.

Tim Schroeder
September 6, 2018, 6:26 PM

@Karen Dolan: I see. I agree that if that's the case, the 3 parameter constructor should be removed entirely. I made a new Issue MH‌-13082 for it. I’ll make a pull request for it as well.

Fixed and reviewed


Tim Schroeder


Tim Schroeder


Incorrectly Functioning Without Workaround

Tags (folksonomy)



Fix versions

Affects versions