Are there any other mechanisms to disable users beyond setting their shell to something like /bin/disabled?
We would strongly prefer to use SAML2 based idp to be consistent with most other web services we have. However, on our actual HPC systems, user shells are defined by their active directory entries - meaning everyone has a valid shell and we cannot change their shell to “disabled” without potentially impacting other services.
Ideally, we would allow users to login, assuming they have valid credentials. Then show a different landing page depending on an users status. If they have access then they can use OOD as normal. If not, they are shown a page, for instance, saying they are not currently eligible and provide instructions for gaining access.
We can achieve this to a degree by using a specialized idp set up specifically for OOD, but we’d prefer not to do this because of the extra overhead, maintenance, and desire to not have ad hoc login services.
You can maybe use profiles if this is an attribute you can pull from Etc. I.e., a unix group or similar?
The idea is you have the base profile which all your customers use, but this other profile is behind some ERB if block and will only render for these clients.
Would there be interest (in the broader community) for something along the lines of a customized landing page with some sort of optional status checking? I’m thinking something similar to how the “no home directory” page can be customized.
It looks like that functionality doesn’t presently exist. While it’s probably pretty straightforward to put an ad hoc solution in place, if we’re going to implement something we’d be interested in sharing it as a PR (both for helping the community and hopefully keeping our deployments closer to reference).
At least for us, I think the basic flow would look like:
Log in to OOD (exists)
Query user eligibility or other properties (to be added – e.g. query LDAP for user properties not available to the idp service or on the system directly)
Conditionally show features / redirect to instructions / etc bases on user properties (to be added)
I don’t really have an idea on when we’ll actually have time to work on that. If we can be a bit more careful and make it at least somewhat more generic than our specific use case, we’d definitely be interested in sharing.
The question is how to gather this information. You suggest querying LDAP - that usually takes privilege to get anything good out of it. Unfortunately no 2 centers are the same, so how can we do this uniformly and securely?
I suppose there’s something you could do during the pun_pre_hook_root_cmd that touches a file you could then inspect as a regular user?
That’s fair. I haven’t thought through whether the mechanics are actually doable (or sane ).
My general thought was it might be possible to add post-authentication hook. Ideally that would be an optional / over-ridable function that could be specific to return whatever extra information is needed. If that has to run in user-space, you are correct that would be a non-starter.
It’s a thought-experiment at this point. We’ll, at some point, likely try to implement something and will definitely share if we’re able to come up with something that is at least somewhat portable. It might still be worth sharing an ad-hoc approach as a customization example too.