I have a few questions on handling users in OnDemand.
Some context: I’m learning Ruby and working on building a Ruby on Rails app on top of Ondemand. So far, I have OnDemand 1.7.14 and Slurm installed on a cluster of Centos 7 VMs. The app is little more than a boilerplate RoR app so far.
I’ve been reading through the documentation and couldn’t figure out how to properly create new users for Open OnDemand. The only user I have working is the original system user I created on my webserver node. I tried creating more system users, but they can’t log into Open OnDemand. Ideally, I’d have a database manage my users, but it looks like they are handled by the OS.
My Ruby on Rails app needs to know which OnDemand user is logged in (name and some sort of unique identifier). I tried looking through the existing OOD system apps, but didn’t have much luck displaying the current user in my app.
Eventually, I would like this app to be able to create, modify, and delete OnDemand users.
Let me know what suggestions you have for creating new users and integrating them into my app, thanks!
OnDemand leverages the OS accounts for users. So there must be a separate OS account per user. In Ruby, the Process.uid gives you the UID of the currently logged in user, because the web server the user is connecting to is running as their self. To get the username of this you can do Etc.getpwuid(Process.uid).name or use our https://github.com/OSC/ood_support gem and do OodSupport::User.new.name
To create more system users and enable them to log into OnDemand you need an Apache authentication strategy and a mapping strategy (for mapping the authenticated user to the system user). The documentation provides some overview on this with many different options. The hpc-toolset-tutorial docker images using docker compose shows an example of OnDemand with Dex (mod_auth_openidc provider) + LDAP for system accounts. Dex+LDAP is the recommended default approach for a new installation of OnDemand if you don’t have access to a preexisting identity provider to use. Also if you don’t need strong security and are experimenting the PAM authentication with Apache Basic auth might be easy to setup as well.
Is Process.uid non-fungible, in the sense that if I create a Ruby passenger app that makes decisions based on Process.uid, the logged in user cannot inject someone else’s UID? My hunch is that as long as write permissions on the passenger app are set correctly such that the user running it can’t modify the code (which should always be the default), then they may be able to see that Process.uid is being used but wouldn’t be able to modify it in flight?