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

Proposal: Add user_expire module + default configuration #3550

Open
joeparsons opened this issue Jul 16, 2024 · 0 comments · May be fixed by #3665
Open

Proposal: Add user_expire module + default configuration #3550

joeparsons opened this issue Jul 16, 2024 · 0 comments · May be fixed by #3665
Assignees
Labels
enhancement New feature or request proposal Proposed change to how something works (usually larger or more fundamental than a feature request)

Comments

@joeparsons
Copy link
Member

joeparsons commented Jul 16, 2024

Motivation

Most AZQS sites utilize WebAuth/CAS for user authentication but rely on manual account creation and the manual addition/removal of AZQS/Drupal roles for user authorization / access provisioning. This means that user access also needs to be manually de-provisioned when someone leaves or no longer requires access which is less than ideal.

Is your feature request related to a problem? Please describe.

Because access de-provisioning typically happens manually it also doesn't always happen when it should.

Proposed Resolution

@maine-inventor mentioned that he has successfully used the User Expire in the past to help with this kind of problem.

We should look into adding this module (or something similar) to Quickstart and possibly maintaining a default configuration that does something along these lines to automatically block access for inactive users to ensure that users that no longer need access to sites have their access removed:

  • Automatically block inactive users with the administrator role after 30 days of inactivity
  • Automatically block inactive users with the content editor or content admin role(s) after 180 days of inactivity

We'd probably also need to add some documentation about how users can be un-blocked by another administrator via the Admin UI or via drush.

Describe alternatives you've considered

We've started to explore the possibility of integrating with different/additional identity and access management services so that we can utilize identity provider attributes (e.g. LDAP attributes or Grouper group memberships) for authorization (see #35) but we don't have solution for that yet.

Roles and Permissions considerations

A clear and concise description of how each of the following roles would be impacted by this change:

  • Content editor
  • Content administrator
  • Administrator

Users with these roles would have their access blocked if they haven't logged in recently enough.

@joeparsons joeparsons added enhancement New feature or request proposal Proposed change to how something works (usually larger or more fundamental than a feature request) labels Jul 16, 2024
@joeparsons joeparsons self-assigned this Aug 19, 2024
@joeparsons joeparsons linked a pull request Aug 23, 2024 that will close this issue
34 tasks
@joeparsons joeparsons added this to the 2.11.x Patch Release Issues milestone Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request proposal Proposed change to how something works (usually larger or more fundamental than a feature request)
Projects
Status: To triage
Development

Successfully merging a pull request may close this issue.

1 participant