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

Possible mechanisms for temporary access #28

Open
kMutagene opened this issue Aug 19, 2024 · 5 comments
Open

Possible mechanisms for temporary access #28

kMutagene opened this issue Aug 19, 2024 · 5 comments

Comments

@kMutagene
Copy link
Member

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.html

Thoughts @muehlhaus @j-bauer ?

@kMutagene
Copy link
Member Author

cc @HLWeil

@TetraW
Copy link
Collaborator

TetraW commented Sep 4, 2024

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?

@Brilator
Copy link
Member

Brilator commented Sep 9, 2024

related to #23

@j-bauer
Copy link
Collaborator

j-bauer commented Sep 12, 2024

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?

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.

@Brilator
Copy link
Member

Unfortunately, paper peer-review is typically anonymous. So I doubt they'd like to login with personal credentials.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants