Possible to create guest account?

[sgy002]

I'm wondering if Dataverse can have a layer of (something like) a guest account that only allows users to request access to restricted files and download access-granted data files (in addition to downloading publicly available files that can be achieved without an account).

This feature is for people outside our organization who want just an access to restricted files.

We got this idea from a dataset of images in our installation that attracts some attention recently. The depositor restricted the image files. We've received two emails from people outside our organization asking to get access to those image files. People need to have a Dataverse account before being able to click the 'Request Access' button.

The workflow in our installation is that we, as curators, mediate the sign-up process. Typically, we only create accounts for those who are sponsored by a current employee for collaboratively uploading data. People inside our organization are automatically granted an account and they log in the installation through Shibboleth authentication.

It's very tricky to change our workflow. We've thought through and determined to remain the status quo. The best solution seems to be this 'Guest Account' that separates users inside and outside our organization.

[BPeuch]

Hello @sgy002,

Doesn't the Request Access button appear for all connected users by default? I thought that was the case, even if you greatly restrict users' default permissions. 🤔

You can also create a custom role that has absolutely no permissions at all. I just tested whether it was possible, and it is:

[qqmyers]

I think that creating such a role, and then being able to assign users to that role based on a group affiliation might be a way to handle this use case. I'm not sure what login options are in use by @sgy002 , but if either the existing Shibboleth or IP groups could be used to distinguish users who should be able to create content from those who don't, then this would work now. If those groups aren't helpful, it may be that the new email-based groups implemented in #6974 for 5.0 might help. I think that would allow, for example, all people @university.edu to be added to a group that create content and all others could be given no permissions.

[scolapasta]

I'm not actually sure what that role would accomplish. By default, a user has no permissions on an object. Assigning that role is the same as having no role.

And if you already have granted some permission to the "all users" group, then assigning that role wouldn't override that.

[qqmyers]

So would one assign the :authenticatedUsers group the FileDownloader role and then use some other Shib/IP/email group to give the DatasetCreator role?

[scolapasta]

I still don't think you'd want to give :authenticatedUsers group the FileDownloader role because they still want to limit access.

Put another way, all user accounts are "guest" accounts in that by default they can only do what anyone can do. If you don't want anyone to be able to something, you don't use the authenticatedUsers group. Rather you define a separate group that you can then assign.

From the orignal post: " Typically, we only create accounts for those who are sponsored by a current employee for collaboratively uploading data. People inside our organization are automatically granted an account and they log in the installation through Shibboleth authentication."

So what I would suggest is to create a new group for these users (manually added users plus the shib group can all be members of this group). Then change any role assignment that has :authenitcatedUsers to this group.

At that point, allow anyone to create an account (these would be the "guest" users). If the installation owner is creating the account for someone with the "extra" permissions, then after they create the account, assign them to the aforementioned group.

[sgy002]

Many thanks @scolapasta for the suggestion! That's brilliant!

Currently, our installation automatically grants Dataverse Creator role to :authenticatedUsers group.

We shall move the existing :authenticatedUsers group to a new group, replicate the permission setting.
The :authenticatedUsers group will be empty and left for people outside my org. Then maybe configure the installation to auto assign the new :authenticatedUsers group File Downloader role...

Let me discuss with my tech colleagues! Will get back to this Issue if we identify any issues.

Thanks a lot to @BPeuch @qqmyers for your contribution as well!

[qqmyers]

@sgy002 - In a side conversation, @scolapasta pointed out to me that the FileDownloader role is what you set (on a given dataset) after someone requests access for files, so I think you want :authenticatedUsers to have no role by default.

[scolapasta]

@sgy002 @qqmyers right, if you auto assign FileDownloader, all authenticated users will be able download any file for which this is auto-assigned (and e.g. if you assign at a Dataverse, download any file in any dataset in that dataverse. i.e. don't do that. :)

No role is fine for the group. Then they would not be able to do anything by default except view public info and request access to files (that have access request enabled). When access is granted, the specific user would get FileDownloader for the specific file(s).

I'm going to go ahead and close the issue, but please feel free to continue to comment / re open if necessary.