My dataverse installation allows users to modify their user data (name, firstname email etc) even when they are registered with the use of institutional login (openId)

[Piotr Wyrostek]

My dataverse version is 5.5. 

Is there any way to correct this problem? I need to know who is using dataverse.

We have some requirement concerning what data have to be supplied when someone registers in our institution and we would like to see this data in dataverse as weel.

Regards, P. Wyrostek

[Philip Durbin]

I'm a little confused because you mention both Institutional Login and OpenID. By OpenID I assume you mean OpenID Connect (OIDC). In Dataverse, Shibboleth accounts (called Institutional Login in the GUI and the docs) cannot be edited (email, name, etc.) while OIDC accounts can be edited.

So I guess my question is, are you talking about Shibboleth accounts or OIDC accounts?

Thanks,

Phil

p.s. We've actually considered making Shibboleth accounts editable, by the way. :)

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/9cfd2fab-2ba9-4bdd-a88a-f288d7489133n%40googlegroups.com.

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin

[Piotr Wyrostek]

Thank you  for your prompt answer. Sorry for the confusion. When I write "institutional login", I mean OIDC.

Is there any way to make OIDC accounts not editable?

Piotr Wyrostek

[Philip Durbin]

No, there isn't. However, you're welcome to create a feature request for this at https://github.com/IQSS/dataverse/issues

The background on this is that builtin accounts have always been editable. Then we added Shibboleth accounts as uneditable. Then we added OAuth accounts and decided to allow edits. Then OIDC which are a form of OAuth within Dataverse at least. I guess I'd say that some installations like the Shibboleth accounts are uneditable and some don't (which is why we went with editable for OAuth). It sounds like there should probably be a system-wide policy on if these "remote" accounts (non-builtin) are editable or not. Previous to this conversation I was thinking we should make all accounts editable.

I hope this helps,

Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/778700af-c0ef-44b2-986d-8c76c3b4a2can%40googlegroups.com.

[Philipp at UiT]

DataverseNO currently uses Shibboleth with the user information not being editable in Dataverse. We are migrating our installation to the cloud, and are right now working on authentication issues. In our cloud deployment, we probably will use two authentication providers, ORCID and Feide, our national authentication provider. Both use OAuth. In our tests, we also realized that the user information coming from these providers is editable in Dataverse.

Before I read this discussion thread, I thought that user information from external authentication providers always should be non-editable, because otherwise it could cause trouble. So, I'm wondering how Dataverse manages user information from external authentication providers. Here are a couple of questions:

1. A researcher logs into Dataverse for the first time using an OAuth-based authentication provider.

a) I guess the user information is pulled from the authentication provider and stored in Dataverse?

b) Is there a minimal set of information that is needed from the authentication provider?

c) I guess the email address is a crucial part here since it's used as a primary user identifier in Dataverse?

2. Let's assume the researcher in (1) doesn't change the user information provided by the authentication provider in the initial login session. But in a later login session, the researcher changes the email address from A to B in Dataverse, but address A is still the email address stored in the user entry in the database of the external authentication provider.

a) What happens to the Dataverse user account? Will there be created a new account with the new email address B?

b) What happens when the user logs into Dataverse next time using the external authentication provider? How will Dataverse be able to recognize that the researcher with email address A wants to log in to an account that now has email address B as its primary identifier?

Best,

Philipp

[Philip Durbin]

Hi Philipp,

How Dataverse manages user information from external authentication providers depends on if we're talking about Shibboleth or all other external providers (OAuth and OIDC). In short, Shib users can't edit their info (email, etc.) and all others can. Now to your questions, which seem to center on OAuth.

When a user logs in for the first time from OAuth as much information as possible is pulled out and presented to the user to confirm or change as they create their Dataverse account. For some providers, such as ORCID, the user can prevent info like email from being sent.

For OAuth providers, very little information is required. All Dataverse really needs is some sort of unique identifier for the user. The user fills in any missing values such as email. The values required by Dataverse are first name, last name, email, and username.

Yes, email is crucial (required) but it is not used as the primary identifier for a user in Dataverse. That's persistentuserid in the authenticateduserlookup table: https://guides.dataverse.org/en/5.4/schemaspy/tables/authenticateduserlookup.html

On to your next set of questions about email.

All users except Shib users are free to change their email address at any time. This has no impact on their ability to log in. For all remote users, the matching is done on the persistentuserid field mentioned above, not email. That unique identifier is how Dataverse knows if it's the same user or not.

I hope this helps!

Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/a08502c4-747e-43da-8990-07201c6eb7c8n%40googlegroups.com.

[Philipp at UiT]

Thanks for clarifying this, Phil!

I guess I mixed up primary identifier with unique identifier, as an email address only can be used once to create a user account in a given Dataverse installation. I have only tested this using local authentication. If you try to create a new user account and enter an email address that is already used in another user account, you get the following message: "This email address is already taken.".

I think an advantage of being able to configure a Dataverse installation to have their "remote" accounts (non-builtin) not being editable is that we have better control on the user data. For instance, in DataverseNO we use a trigger solution in the database which assigns user access rights to collections based on their email address (all users with a ...@uit.no address get access to the UiT collection and so on). If users can change their email address to their personal email address, this automatic assignment won't work anymore.

How much work would it be to make "remote" account editability configurable? Is it more like changing one or a few parameters in the code or more like a major redesign?

Best,

Philipp

[Philip Durbin]

I'd say it's a fairly major redesign, making it configurable for remote accounts to be editable or not. (A "large" in the terms we use during sprint planning.) In my head https://github.com/IQSS/dataverse/issues/3486 represents this work but I closed it a while ago because it hasn't been a priority. There are some links in that issue you might find interesting.

Incidentally, instead of an external trigger, these days you can create groups based on email addresses, thanks to a contribution by Oliver Bertuch: https://guides.dataverse.org/en/5.6/admin/mail-groups.html

Thanks,

Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/d7726fc9-30c6-44a7-87cf-0cc746aad598n%40googlegroups.com.