-
Notifications
You must be signed in to change notification settings - Fork 492
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
As an administrator, I would like to create groups of people based on their email address domain #6936
Comments
Thanks @poikilotherm. In Harvard Dataverse we use a Harvard-wide Shibboleth group to manage access to Harvard licensed data collections, so the general use case is sound. Thanks for thinking of verified email addresses. :) I'll poke the team on the IQSS side as well as @qqmyers to see if there are any concerns about the proposed implementation, but I understand the use case. If you already have the code, feel free to put up a draft PR. |
Seems like it could address some of the use cases from #1515 as well. Off-hand, I don't see any issues. |
I'm starting work on this. If someone is curios, please feel free to look at https://jugit.fz-juelich.de/fdm/dev/dataverse/-/compare/fzj...6936-fzj-domaingroups Beware, this is for now against 4.19 base in our fork, as we need this ASAP. A PR to upstream will of course be against develop 😉 |
… to use in some places. IQSS#6936
…tructure. Still lacking tests, API endpoints etc. IQSS#6936
…ction function static. IQSS#6936
… included in group searches. IQSS#6936
…N parsing/printing). IQSS#6936
… service and entity layer. IQSS#6936
…Lacking deletion support. IQSS#6936
…the extended exception handling. IQSS#6936
…of MailDomainGroup. IQSS#6936
…group alias as the identifier everywhere. IQSS#6936
…NGLE_TABLE inheritance strategy. IQSS#6936
Until some other (better) approaches to auto map user attributes from authentication providers to groups are ready, I would like to introduce a very simple group provider based on mail addresses.
The idea is to take the domain part of a users mail (like
@fz-juelich.de
for me) and place everyone with that domain in a group. What domains are mapped should be configurable.This is a very simple and basic approach to grant permissions to people coming from your home institution, while externals might access and use your dataverses, too.
Should of course be able to handle more than one group in multi tenant installations...
And obviously will only do this if email is verified and confirmed... ;-)
If this is of interest for more people out there, I'm happy to contribute this as an upstream patch.
(This is another step to make Jülich DATA ready for real traffic quickly...)
The text was updated successfully, but these errors were encountered: