You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is at odds with the CAS implementation we are working on, and would conflict with efforts to link specific PU netIDs to any jobs the software is used to submit to the cluster. Presumably we will want to remove the option for people to register with their own usernames and passwords and allow only SSO.
Conversely, the CAS implementation being tested as of Oct 2024 currently would allow anyone with a PU netID to sign into the software (maybe okay) and start running compute-intensive jobs (not okay) without approval.
To-dos:
Assess what kinds of limits can be automatically placed on new user accounts.
Storage limits?
Compute limits?
Are there other options?
Check in with RC, PUL to discuss preferred strategies.
Determine what level of access someone with a netID should be able to have to the instance without approval.
No access?
Access to non-compute-heavy features?
Access with particular storage limits?
The text was updated successfully, but these errors were encountered:
We will want to determine appropriate handling for new users, in conversation with RC and PUL. The default handling by eScriptorium is as follows:
This is at odds with the CAS implementation we are working on, and would conflict with efforts to link specific PU netIDs to any jobs the software is used to submit to the cluster. Presumably we will want to remove the option for people to register with their own usernames and passwords and allow only SSO.
Conversely, the CAS implementation being tested as of Oct 2024 currently would allow anyone with a PU netID to sign into the software (maybe okay) and start running compute-intensive jobs (not okay) without approval.
To-dos:
The text was updated successfully, but these errors were encountered: