What's the deal with TPA hinted links in Nutmeg/Olive?

Hi all, I’ll join in here as I’ve been testing the same :slight_smile:

Interesting, so I tried the following example:

https://<hostname>/courses/course-v1:<course-id>/courseware/<location_id> : this redirects me to the login page.

So, that URL should then work with tpa_hint right?

But, if I try:

https://<hostname>/courses/course-v1:<course-id>/courseware/<location_id>?tpa_hint=saml-<slug>: I am also redirected to the login page, I do not get logged in and redirected but I do see in the URL that the next parameter is added as:

https://<hostname>/login?next=/courses/course-v1%3Acourse-id>/courseware/<location_id>/<location_id>%3Factivate_block_id%3 …

To add to what Maari said, the documentation on TPA hinted links specifically uses a course link in its example for a TPA hinted URL, so it would be surprising if TPA hints somehow weren’t expected to work with course links. :slight_smile:

So, I now enabled the MFE’s on the site again and noticed this:

  • https://<lms-hostname>/u/<myusername>?tpa_hint=saml-<slug>: I get logged in and redirected to the Profile MFE page
  • https://<mfe-hostname>/profile/u/<myusername>?tpa_hint=saml-<slug>: I am also logged in and redirected to the Profile MFE page

Same happens with the account page:

  • https://<lms-hostname>/account/settings?tpa_hint=saml-<slug>: I am logged in and redirected to the Account MFE page
  • https://<mfe-hostname>/account?tpa_hint=saml-<slug>: I am also logged in and redirected to the Account MFE page

So that means that the TPA hints work with the mfe-hostname, even without the frontend-app-authn being enabled?

Or has it something to do with the flags we set, the learner_profile.redirect_to_microfrontend and account.redirect_to_microfrontend?

As I mentioned above, https://<lms-hostname>/courses/course-v1:<course-id>/courseware/<location_id>?tpa_hint=saml-<slug> redirects me to the login page (I don’t get logged in nor redirected)

And if I try any URL that points to course content in the Learning MFE:
https://<mfe-hostname>/learning/course/course-v1:<course-id>/ ... while I am logged out (with or without the ?tpa_hint=saml-<slug> addition), I don’t even get redirected to the login page, instead I see “There was an error loading this course.”:

Internal Server Error: /api/courseware/course/course-v1:<course_id>

TypeError at /api/courseware/course/course-v1:<course_id>
Field 'id' expected a number but got <django.contrib.auth.models.AnonymousUser object at 0x7fd3513d6b20>.

Is there a specific way to construct URL’s pointing to course content with the Learning MFE that I am not aware of?

Is there a way to tell the LMS to redirect to the Learning MFE similarly to the account and profile pages?

@mrtmm @fghaas Hmm, in that case it looks like whatever code is adding the activate_block_id parameter is also stripping out the tpa_hint - perhaps this line. But what I don’t understand is that that code hasn’t been changed in years from what I see in the git history.

Okay, so maybe tpa_hint URLs have been broken in the courseware for ages and the documentation is stale. But this bit still holds true:

So, do we have a way to make this work with the Learning MFE, in Nutmeg?

Looks like this is a prime candidate to be added to the community testing plan. @Dean, is there still time to add something to the list? @fghaas, would you or @mrtmm be willing to be assigned the testing?

If the unannounced deprecation is confirmed, I’m of the opinion it’s a bug and we should rally around fixing it.

Okay so if I read it correctly, then the community testing plan presently doesn’t seem to include testing TPA against SAML IdPs at all (it only mentions Facebook, Google, and Microsoft SSO which, if I remember correctly, all use OAuth2). So just so I understand what testing would entail, do I understand correctly that we would

  1. set up a SAML IdP (where? Would https://samltest.id/ work, or does tCRIL/2U/someone else have a reference SAML IdP instance set up for this purpose?);
  2. configure the demo instance to authenticate against that SAML IdP as a TPA provider;
  3. test whether regular TPA works correctly for SAML (presumably covering both the registration and the login workflow);
  4. test whether TPA hinted links work with SAML?

If so, then in order to do meaningful testing it would be good to understand how TPA hinted links should work against the learning MFE, and how TPA in general is meant to work with SAML with the authn MFE, which is something that hasn’t become entirely clear in the thread that I cross-referenced. :slight_smile: Can you help shed some light on that?

It just occurred to me that I might be dragging this thread off on a tangent which I don’t think I want to do; should we open a separate topic instead?

1 Like

Hello @arbrandes and @fghaas.

Yes new Test Cases (TCs) can be added. The normal procedure is:

(1) Add your idea/request to the SUGGESTIONS tab in the Community Testing Plan: Olive - Open edX® Community Test Plan - Google Sheets

Create a comment and assign me if it’s urgent and you want it in right away, so I can bring it up with BTR group in Slack immediately to see if there are any objections.

(2) If approved, it will be added the very next Friday. i.e. we will add new test cases on a weekly cadence. (or it can be added sooner, on the same day if it’s urgent, if it gets verbal/written support from senior BTR members like you etc).

Feel free to tell me what you want, I’m just here to coordinate.

Great stuff, thanks!

@fghaas indeed to me this sounds exactly like the flow of the testing for this proposed test case!

You’ve been added to the Test Sheet in case you want to assign yourself to something in the meantime:

Is Cleura is your chosen company name to represent yourself in the community?

Yeah hold on a jiffy please, I’m not volunteering yet because I’d quite like to know what testing would actually entail, hence my question above. We’re still quite busy getting all our platforms to Nutmeg, precisely because the combination of Learning MFE and TPA has been a rather bumpy ride considering the authn MFE didn’t make it into Nutmeg. So I need to know how much time we should realistically expect to put into testing Olive, and how much time that’ll take out of our Nutmeg migration budget.

1 Like

That seems to be the case, yes, for the simple fact nobody suggested it… yet. :slight_smile:

First question I’d raise is if TPA hints work with OAuth2. If they don’t, it might reduce the set of test cases: we could just test TPA with OAuth2, which might make the process easier (since folk are already testing for Oauth2 anyway).

I’m not aware of reference SAML IdPs, but I can’t speak for 2U. I don’t think anybody’d object to samltest.id, though, if with that we can achieve the results we want.

We’d have to take this one up with @regis, who AFAIK is managing the demo server tests are conducted against. He’ll probably just ask for a PR to GitHub - overhangio/openedx-release-demo: Open edX Olive demo platform CD with the workflow changes that would set the integration up.

Otherwise, yes, I figure that is what testing would entail.

I don’t have an answer for either. @jristau1984, I’m told you might be the one to ask about the Learning MFE - any clue on TPA hinted links?

Good call. I moved the tail end of the thread to where you asked the question originally.

Re “just”. :smiley:

I just remembered that Tutor core doesn’t concern itself with SAML TPA at all — we’re still using a YAML plugin for that in production, but since the v1 Tutor plugin API came out, we’re kinda not really supposed to use YAML plugins anymore. So it would be a Python plugin like in the documentation example, which if I read the GitHub Actions workflow definition for the CD demo correctly, would need to be published separately on GitHub.

Or is the idea that the CD platform should run as few Tutor plugins as possible? In that case I’m not sure if SAML functionality is even supposed to be included there?

Btw, I’ll use this as an argument to include it in Tutor/Olive. Nobody else in BTR felt a pressing need to do so, but this sounds like it’s a clear necessity, feature-wise. (I haven’t looked into it, but I’m assuming the authn MFE will be needed for TPA.)

Sorry, didn’t mean to imply this would be simple, necessarily. :sweat_smile:

I believe the plan is to make any plugins available that are required by the test plan. If any such aren’t there, it’s likely because they weren’t upgraded to Olive yet.

1 Like

Let me try to clarify a bit my own personal position regarding plugins.

  1. The demo platform is meant to test the Olive version of Tutor and plugins which are important to the community. I understand that “important” is a vague term. To me, this covers official plugins (under the overhangio Github org) but also others that include mission-critical features, such as the codejail plugin.
  2. I think that TPA is a mission critical feature that should be counted among the “important” plugins.
  3. I acknowledge that we currently do too little to designate and promote “important” plugins. The Tutor indices TEP is meant to resolve that.
  4. I have no issue whatsoever with YAML-formatted plugins. I think it’s perfectly fine to distribute your plugin in the form of a YAML file. Still, I think that the v1 API is better, more capable, and thus I would encourage you to take the time to migrate your plugins.
1 Like

I hope you don’t mind me asking this question: if it’s a mission critical feature, then why should it rely on a plugin? Shouldn’t mission critical features be in Tutor proper?

Essentially for two reasons:

  1. Integrating this optional feature in the Tutor core codebase makes life more difficult for its maintainers (i.e: me, for the moment). Spreading the features across plugins makes it easier to distribute responsibility and manage the whole Tutor project.
  2. Many users do not care about TPA. Adding TPA config to Tutor core would make documentation and administration more difficult for them.

This is the same reasoning behind the integration of Ecommerce, Notes, MinIO, Codejail, etc. as plugins.

I’m afraid I don’t quite follow. So is it mission critical or optional? The way I use those words something can be either one or the other, but not both.

Is it really that many? As in, would you argue that a majority of Open edX platforms require their learners to sign in with only a username and password, and don’t let them use their organization’s existing SSO service, Google, or Facebook to authenticate? I don’t have access to overall community statistics, but purely on a hunch I’d doubt that that assertion is true.

At any rate though, suppose we don’t want TPA in Tutor core, then what do we do to include it in community testing? I ask because

  • SSO testing is already in the community testing spreadsheet,
  • TPA is not enabled by default in openedx-platform,
  • (unless I’m mistaken, and unless we add it to Tutor core) without a Tutor plugin TPA/SSO won’t work,
  • thus — again, if I understand things correctly —, for this to be testable within the Olive demo environment, such a plugin would need to be published and added to the demo environment’s GitHub Actions workflow.

I may be missing something though, and would be happy to stand corrected. @mgmdi, if I read the community testing spreadsheet correctly, you are the assigned tester for SSO testing on the Olive demo platform so I am sure you have thought about this more than I have — would you like to chime in and correct me please? :slight_smile: