Collecting Ideas: Centralized Access Control to xBlocks (esp. wrt. proctoring)

[mroytmanedx (Michael Roytman)]

Thank you for your feedback, @dave! There is a lot to consider here, and I appreciate you laying out these different options and potential roadblocks.

I like your JWT idea, and it would work well for us. I knew that the centralized access control was a lofty idea and that it’s probably not the ideal time to embark on that journey. I do have some other thoughts.

Clarification Questions

@dave

Would a new user partitioning type help here, where people are swapped into and out of the group that can see the exam? (I’m honestly kinda skeptical of this one, honestly.)

I had thought about user partitioning as a way of implementing this. We’d need to create a REST API to call from the special exams service. What are your reservations about this idea?

@dave

We currently conflate permissions with composition in a way that I don’t think we should. Permissions are used to implement “which A/B test content should we show the student”, in addition to “is the student allowed to access the test”. I believe these should be better separated out.

What do you mean by “composition” here? Which of “which A/B test content should we show the student” and “is the student allowed to access the test” is “permissions”, and which is “composition”?

JWT Token

I have mostly followed your idea.

The one thing I’m unsure of is who issues the JWT. I imagine it would the special exams service. It has the business rules to mostly determine whether a learner should have access to exam content, and it can create and sign a JWT with its private key. As the learning MFE makes requests to the special exams service, the special exams service will send back a JWT to the learning MFE if something happens that grants the learner access to the exam (e.g. the learner starts the exam, etc.). The MFE then forwards the JWT token in a cookie to the LMS’s render_xblock view. The LMS, which will (somehow) have the special exam service’s public key, will verify the signature and the claims in the JWT.

That makes sense to me. However, I thought the LMS was the only OAuth authorization server and would be issuing JWTs, per OEP-42. Has that changed?

Am I missing something here?

Other Options Specific to xBlock Loading/Rendering

There are a few other mechanisms that could get us what we want, I think. If we instead develop special exams as a plugin, then we could leverage the following.

1. We, theoretically, could add a filter hook to the render_xblock view - something like RENDER_XBLOCK_REQUESTED. Plugins could register pipeline_steps that run to modify the context that’s sent to the template that would show or hide the content or to raise exceptions to block rendering entirely. I think this would similarly be too slow and cause operational issues, though.

2. I did find references to Plugin Contexts described in edx-django-utils, which seems to implement the general idea above without filters: “This means that a plugin will be able to add context to any view where it is enabled.” Although, it appears to require theming, and I know very little about that.

3. I came across this thread, titled Pluggable access control both viewing and enrolling in a course. I haven’t read through it in its entirety, and it looks like it concerns courses and not xBlocks. Nevertheless, I wonder if a pipeline of access control processors, defined within individual plugins that describe access controls relevant to the plugin, could be used to determine access to an xBlock. It reminds me of the pipeline_steps in the hooks framework or the third party authentication pipeline.

Plugin or IDA?

Since some solutions lend themselves better to plugins and others to IDAs, what are your thoughts about whether the special exams “service” should be an IDA or a plugin? I cannot find advice on when to consider one over the other. Special exams, which would encompass proctoring and timed exams, are an extension to the core courseware and the learning subdomain. And when I read about the drive for easier extension of the platform, I see mainly investment in plugin architecture. Are “extensions” synonymous with “plugins”? How do IDAs or micro-services fit into this?

I feel that keeping the special exams service a plugin would align better with the Architecture Manifesto, as I understand it. I feel that enabling special exams should be as simple as installing the special exams plugin. Standing up a separate micro-service to enable special exams seems like a big lift. However, your JWT idea lends itself well to a special exams micro-service.

My understanding is that our main justification for an IDA was decoupling the deployment of the special exams service from that of edx-platform.