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

API - update an authenticated user #7679

Closed
veustp opened this issue Mar 12, 2021 · 9 comments
Closed

API - update an authenticated user #7679

veustp opened this issue Mar 12, 2021 · 9 comments

Comments

@veustp
Copy link

veustp commented Mar 12, 2021

feature request:
currently on version 4.20 of Dataverse
Authenticated (shibboleth) users are uploaded from the central personnel system.
Creation via API is no problem (POST http://$SERVER/api/admin/authenticatedUsers).

However, users sometimes change their preferred emailaddres (a first- and last name change is far less prevalent).
We would need to be able to update the email address via an API call.
Is there a PUT version of the ../admin/authenticatedUsers API?

br,
Pieter

@pdurbin
Copy link
Member

pdurbin commented Mar 12, 2021

No, there is no API for updating users info (email, etc.) via API. Typically users update their own info (via the GUI) but it sounds like you'd like an API for a superuser to update user info via API.

@veustp
Copy link
Author

veustp commented Mar 12, 2021

That's correct - We upload the user data ourselves to assign the users to specific dataverses via groups. The users do not self-register. Their shibboleth attributes do not allow assingment to a specific dataverse... which is why we upload their data and maintain their data via uploads... Hope this clarifies why we are looking for such an API.

@pdurbin
Copy link
Member

pdurbin commented Mar 12, 2021

Ok, but since you mentioned Shibboleth you should be aware that on login, user info (email, name, etc.) is updated for Shibboleth users. Here's how we express this at https://guides.dataverse.org/en/5.3/user/account.html#edit-account

Please note that you cannot edit your account information within Dataverse if you use the Institutional Log In option. Instead, you should contact your institution to change your name, email, etc. Once the change is made by your institution, it will be reflected in Dataverse the next time you log in. Users of the Institutional Log In option are not required to verify their email address because the institution providing the email address is trusted.

That is to say, it's doesn't make much sense for you to edit user info for a Shibboleth user (using a new superuser API) who then logs in and has that user info overwritten with values that may be different (Phil vs. Philip for example).

@veustp
Copy link
Author

veustp commented Mar 18, 2021

Agreed -
Additional question on the subject: the API for creating (shibboleth) authenticated users does not seem to accept affiliation information. what is the reasoning behind that?
If not possible via API - is it possible to set affiliation from shibboleth attributes?

@pdurbin
Copy link
Member

pdurbin commented Mar 18, 2021

For Shib users, "affiliation" comes from the name of their institution ("Harvard University" or whatever) in the "DiscoFeed". Please see https://demo.dataverse.org/Shibboleth.sso/DiscoFeed for what I'm talking about.

Also, I'm confused. There is no API for creating Shibboleth users. I assume you mean the code that results in a Shibboleth user being created.

No, it's not possible to change the affiliation for a Shibboleth user. Like name and email, these attributes are overwritten on every login.

I will say that we design the Shib experience first and when in came time to design OAuth support we changed our minds and decided to let users update their name, email, affiliation, etc. If you'd like Shibboleth users to be able to do this (perhaps it would be configurable), please open an issue.

@veustp
Copy link
Author

veustp commented Mar 19, 2021

Hi @pdurbin,

Thanks for following up on this.
I'll try to make our case a bit more clear...

There is an API for creating authenticated users (POST http://$SERVER/api/admin/authenticatedUsers).
The reason for pre-loading users is that we want our users (who will authenticate through Shibboleth) assigned to an explicit group that has the appropriate rights to work in a subdataverse that is specific for their department/unit.
When pre-loading, we use the aforementioned API.

The affiliation resolves to 'default' in our situation - so I'm not sure which Shibboleth attribute we are missing here.
But in any case none of the shibboleth attributes currently available would probably do as we would like to have a more exact affiliation in the user record (not just Catholic University Leuven but more fine-grained: e.g. department of theoretical physics).
Which is why we are looking at the API for setting the affiliation.

Moreover, what we really would like to accomplish is that their username (which is the university staff Id) is somehow entered into their created dataset's metadata. As far as I can tell, the depositor contains the last+first name, not any other user information (username & affiliation). First and last name are not sufficient when trying to identify the owner of the dataset (for statistical purpose later).
At the same time we would also like to bring the user's affiliation into the dataset's metadata and were hoping to accomplish that via the affiliation field in the user record.
Adding the user as author could already bring the affiliation in but still it needs to be added manually - it will not be taken from the user record.

Even more, it would be a nice feature if adding additional authors from the institution could be done by selecting them from the user list - that would -in our ideal scenario- bring their names, username and affiliation into the dataset's metadata.

Another approach would be to have an authority database for our users (univeristy staff) or being able to link to (multiple external) authoritiy databases...

Anyhow, I hope it's more clear to you what we are trying to accomplish.
Does that/our approach make sense?

br,
Pieter

@pdurbin
Copy link
Member

pdurbin commented Mar 19, 2021

There is an API for creating authenticated users

Woof, you're right and I was the one who added it! That was back in b622694. I wonder if I added it for testing but I'm glad you're finding it useful!

The affiliation resolves to 'default' in our situation - so I'm not sure which Shibboleth attribute we are missing here.

Have you looked at :ShibAffiliationAttribute as a possible solution? I haven't played with it myself but it was added in pull request #6729 and the idea is that you can get the attribute from a specific Shibboleth attribute such as "ou" (organizational unit).

Moreover, what we really would like to accomplish is that their username (which is the university staff Id) is somehow entered into their created dataset's metadata.

This only happens for ORCID users. If an ORCID user creates a dataset, their ORCID ID is autopopulated in the "author identifier" field. We don't do this for any other author identifiers. If you're pretty sure you want this, please create a separate issue for it.

Even more, it would be a nice feature if adding additional authors from the institution could be done by selecting them from the user list - that would -in our ideal scenario- bring their names, username and affiliation into the dataset's metadata.

Yes, I agree. There might be an existing issue for this but I don't remember. Either way, a separate issue would be great.

Another approach would be to have an authority database for our users (univeristy staff) or being able to link to (multiple external) authoritiy databases...

This reminds me of controlled vocabulary discussions that are ongoing. There's a meeting on Thursday if you're interested: #7072 (comment)

@pdurbin
Copy link
Member

pdurbin commented Oct 1, 2022

@veustp just checking in. Any interest in making a pull request?

@veustp
Copy link
Author

veustp commented Oct 3, 2022

@pdurbin, I'm not longer working with DataVerse. So, no thanks.

@veustp veustp closed this as completed Oct 3, 2022
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

2 participants