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

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:

@fghaas: hello there!

I’m curious, why would you need a tutor plugin for TPA/SSO to work? I’ve been testing changing the site settings (at least that works for now while site configurations still work :sweat_smile:).

The current tests cover the authentication flow using TPA identity providers, and it would be a great addition to add the other documented capabilities.

1 Like

Aside from the testing plan for Olive, does anyone have any ideas how to make this work in Nutmeg?

At least, is it possible to make the hand-crafted URL’s work with the Learning MFE?

I did found a workaround but it’s absolutely not ideal. It work as follows:

  1. Find the page you want to land on, in the legacy LMS and url-encode the path, for example: %2Fcourses%2Fcourse-v1%3Afoobar%2Bmycourse%2Bmyrun%2Fcourse
  2. Construct the URL with that path as the next parameter: https://<legacy-lms-hostname>/auth/login/tpa-saml/?auth_entry=login&next=%2Fcourses%2Fcourse-v1%3Afoobar%2Bmycourse%2Bmyrun%2Fabout%idp=<slug>

This will log you in and redirect to the next url, but only to the legacy view.

Now, in order to get redirected to the Learning MFE after being successfully logged in,

  1. add a redirect in /admin/redirects from that legacy path to the equivalent Learning MFE URL, something like: /courses/course-v1:foobar+mycourse+myrun/course —-> https://<mfe-hostname>/learning/course/course-v1:foobar+mycourse+myrun/home

Once the redirect exists, the constructed URL will log the learner in and redirect to the course page in the Learning MFE.

However, shouldn’t the legacy LMS redirect to the Learning MFE by default? Is there a flag to enable it? Is there any reason why it’s not doing that? Could there be a better workaround for this?

Sorry for the long wait; thanks for replying and thanks for your patience! I now realise where my miscalculation came from:

Since we do use a plugin (to enable SAML), and followed this documentation when we wrote it, I had always assumed that we would need a plugin if we wanted to support any kind of TPA. That, it turns out, is an incorrect assumption. :slight_smile:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.