-
Notifications
You must be signed in to change notification settings - Fork 3
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
Possible mechanisms for temporary access #28
Comments
cc @HLWeil |
It seems, that the Guest users are only available in the GitLab ultimate (paid) tier. But there is something similar called External users. But I don't know if the user creation can somehow be automated with Keycloak. @j-bauer can you maybe have a look? |
related to #23 |
Dedicated accounts in Keycloak would work, but the persons still would need know/manage a password for that. It was @TetraW 's idea but just as an fyi: @TetraW had the idea to use ORCID logins for that purpose. Not ORCID account linking like it is currently implemented in they DataPLANT keycloak instance but to allow login with ORCID in the datahub directly. These could then be marked as external users which can only access repos they are explicitely granted access to. One side effect would be that we could no longer automatically forward the user to the keycloak login page when clicking on "sign-in" but there would be a choice on the gitlab page to choose between "login with dataplant account" and "login with orcid". People with an orcid link to their DataPLANT account might be confused by this, since the DataPLANT-Account-ORCID link is exclusively on the Keycloak side. Ideally, the account linking within the DataHUB would also work if the person logs in with the same ORCID account that was linked within the dataplant Keycloak. We will test this and report back. |
Unfortunately, paper peer-review is typically anonymous. So I doubt they'd like to login with personal credentials. |
There exists the need in the community to easily share private ARCs without the need to sign up. The prime use case here is that potential reviewers of a paper need to have access to an associated ARC, but do not have (or not want) an nfdi4plants account.
My first idea would be a mechanism that creates a temporary user that has read-only access to the selected ARC.
Gitlab seems to provide a
Guest
role, so maybe that is the way to go? https://docs.gitlab.com/ee/administration/guest_users.htmlThoughts @muehlhaus @j-bauer ?
The text was updated successfully, but these errors were encountered: