Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowing Use of RemoteAuthVariableName authentication without automatically creating Read-Only Users to Modules in Resources and Organizations #780

Open
streatim opened this issue Nov 11, 2024 · 0 comments
Assignees
Labels
enhancement This is an enhancement (not a bug) nice to have Not urgent but would be useful

Comments

@streatim
Copy link
Collaborator

At present when users don't use the Authentication Module, they can use a $_SERVER variable instead. We're using this at UM-Dearborn because we'd rather our users authenticate using the campus' Weblogin than manage a second login stored in CORAL. It appears, though, that there's a presumption in the Organizations and Resources modules that if users can authenticate into the page it must be okay for them to have at least Read-Only access; a comment in the setuser.php:25 file for each module describes this assumption:
//if the user doesn't exist in database set them up with shell user account (we assume that since they were authorized to come in they can create new requests and view existing)

This behavior is different from the licensing and usage modules, which instead directs users to not_available.php if they aren't authorized to access the module even when using local authentication. Generally, it would be nice for the Resources and Organizations modules to also have this option because, while the accounts are read-only, administrative login information is held there.

I wanted to officially recommend that there be a setting in each module allowing users to decide whether shell accounts are created for that module or if unauthorized users are just blocked automatically, and to code that option into the user.php file. This would help lay the groundwork for a consistent experience across the modules rather than have CORAL create shell accounts for some modules and block unauthorized users from others, without any opportunity to configure which is which.

@streatim streatim added the enhancement This is an enhancement (not a bug) label Nov 11, 2024
@streatim streatim self-assigned this Nov 11, 2024
@streatim streatim added the nice to have Not urgent but would be useful label Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This is an enhancement (not a bug) nice to have Not urgent but would be useful
Projects
None yet
Development

No branches or pull requests

1 participant