User authorization requirement (OOD 1.7.0)


In our environment, we are authenticating our users via Shibboleth against ADLDS. Authentication works well, however we are having an authorization issue. Right now, any user with login credentials in the domain (i.e., every student, staff, and faculty member as well as a number of contractors and former students) is able to access Open OnDemand. Most can’t do anything more than that - unless they have been granted HPC user accounts, they can’t queue up jobs. In a few cases, though, we have found that users who once were authorized for HPC cluster access are still able to upload files, as we don’t typically archive and purge users’ home directories unless we know that their relationship with the university is terminated permanently or unless they specifically ask that we do so. This is a problem for us. We would like to be able to restrict access to Open OnDemand to only those who possess active login shells and home directories on our cluster. Is there a good way to do this?

Thank you,


We have MySQL database with our HPC usernames and cpu limits in it. I used the

user_map_cmd: /path/to/my/app

in portal.yml to run an app that checks the already authenticated by shibboleth username against that DB to solve the same problem. This app is also charged with making the user’s home directory on the first login.


Currently in nginx_stage we do the equivalent of this:

require 'etc'
if Etc.getpwnam("username") == "/access/denied"
  # don't start PUN
  # start PUN

This was added a while ago here

In /etc/ood/config/nginx_stage.yml you can change what the disabled_shell is (from its default “/access/denied”).

Seems like this won’t work for every site - including OSC:

The getpwnam() function returns a pointer to a structure containing the broken-out fields of the record in the password database (e.g., the
local password file /etc/passwd, NIS, and LDAP) that matches the username name.

At OSC I think we prevent login via our identity provider if you are denied access. If you were able to keep the /etc/passwd file on the ondemand node up to date… that might be an option.

Seems like we need more robust ways to check for this…