App Access Control in Open OnDemand v3.0.1

Get Help
1

Hi Support,

We have two classes, Class A and Class B, and we want to restrict access to the class apps so that only Class A users can access the app for Class A, and only Class B users can access the app for Class B. We would like to implement App Access Control in Open OnDemand, ensuring that the menu item for each class app is only visible to members of the corresponding user groups. Could you please provide a detailed procedure for implementing this? Thank you.

2

You have a couple options.

The first approach is likely simpler, but would require a new file for each class.

Basically you have an application, let’s call it jupyter just for the sake of simplicity. So you deploy the application jupyter that everyone can see and that’s all fine.

What you do is - you configure sub app for each class. Specify everything you need in the sub app, and set a FACL on the file such that only members of Class A can see it (I assume members of Class A are a part of a Unix group for that class).

So you’d have one app that has everything, but the users use the variants you’ve supplied as sub apps. This is how bc_desktop works. We supply the application bc_desktop but you’re providing different variants (sub apps) of that original application.

https://osc.github.io/ood-documentation/latest/how-tos/app-development/interactive/sub-apps.html#sub-apps-and-reconfiguring-exsting-apps

The second approach is what we at OSC do. It’ll require a bit of Ruby knowledge to know how to parse and interpret the metadata you put in the cluster.d YAML.

First you can add all the classrooms A & B (and C when it comes) to the cluster.d file.

Here’s an example of how to use that fucntionality (it covers specifying queues, but the concept is the same).
https://osc.github.io/ood-documentation/latest/tutorials/tutorials-interactive-apps/add-custom-queue/global-static-list.html

Here’s a snippet of what ours looks like. The key is the app type, classroom name plus additional fields that specify different customizations and options to provide to that class. The value is the accounting ID we use for the class (a UNIX group)

  custom:
    classrooms:
      jupyter/AI_BOOTCAMP_OSC/1/3: "PZS1124"
      jupyter/ASTRONOMY_8824_OSU: "PAS2055"
      jupyter/CCBBI_WORKSHOP_OSU: "PAS2237"
      jupyter/CS_5152_6052_UC: "PES0801"
      jupyter/CS_5135_6035_UC/1/1/owens: "PES0808"

Then in the application you read and interpret this YAML. Here’s our classroom app for jupyter where it reads this YAML and configures the form based off of that data (again, you have to know a little Ruby to see what’s going on here)

3

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