user affiliation and Shibboleth

[Péter Király]

Hi,

for our users in Göttingen the users' affiliation string is "Dienste
der GWDG". GWDG is the IT service provider of the Göttingen Campus,
which covers different institutions (the university, research
institutions within the Max Planck Society, and other research and
educational institutions).

I investigated the source code and I found that ShibServiceBean's
getAffiliation() is responsible for reading the affiliation string.
For my surprise the method is reading from the DiscoFeed, where we
have only one entityID and it has two DisplayNames (one in German, one
in English). The necessary result of this, that each user will have
the same affiliation inside Dataverse which is wrong, it is not their
affiliation at all, but the name of the service of the service
provider.

I do not know the details of Shibboleth communication, but should the
affiliation rather read from some person-dependent Shibboleth
response, like the one happens during login? Maybe the current setup
fits to most of Dataverse instance, but seems for us.

Any idea would be welcome!

Best,
Péter

--
Péter Király
software developer
GWDG, Göttingen - Europeana - eXtensible Catalog - The Code4Lib Journal
http://linkedin.com/in/peterkiraly

[Philip Durbin]

Hi Péter,

It sounds like you have a similar setup as https://dataverse.no where users always select a single IdP (called "Feide" for DataverseNO) and then users get a second dropdown to select their institution ("UiT" for example) within the IdP. I'm attaching some screenshots to show what I mean.

This is in contrast to installations like https://dataverse.unc.edu or https://dataverse.tdl.org where users find their institution in the *first* dropdown, within Dataverse. There is no second drop down for users of these installations.

We were warned of setups like yours in https://github.com/IQSS/dataverse/issues/2548 but we didn't get around to working on it. The person who opened that issue for https://dataverse.nl has moved on and I see they've forked and customized their login page. Unfortunately, I don't have an easy fix. Dataverse uses EDS* and we might need to switch away from it to support your use case, which is probably a lot of work.

I think a more achievable path forward (that I think we want to do anyway) would be to treat Shibboleth more like OAuth login (ORCID, Google, and GitHub) and let users specify their affiliation rather than always overwriting the affiliation based on what is asserted by the identity provider. (We would also allow Shibboleth users to specify their name, email, and username.) Merce and I talked about this idea a long time ago in this "2015-04-30 Dataverse User Accounts and Auth Meeting" doc: https://docs.google.com/document/d/157sw9gaFGwrb0EtCGGlLMxSg0cooHfKEvIsjcebPcA8/edit?usp=sharing . This would also help with situations where the identity provider doesn't give us the email address, for example. If we don't get the email address, we would just ask the user to give us one, like we do with OAuth.

This is a deep topic and I hope what I'm saying is making sense. I'm open to ideas and pull requests for how to improve the situation.

Please keep the questions coming.

Thanks,

Phil

* https://www.shibboleth.net/products/embedded-discovery-service/

--
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 post to this group, send email to dataverse...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CABFhGtnAktc6ZE2opbwkvQ0%2Ba1rd-2cM0sXDc9VGj6MM5SDGsg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

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

[Péter Király]

Dear Philip,

thanks a lot for your explanation! For us it might be a correction to
add a more general term into the DiscoFeed. Another solution would be
to implement a business logic change inside Dataverse. It would have
multiple components (all of these are pseudo code):

1) adding an optional configuration setting about the source of
affiliation with two options:
- DiscoFeed (default value, and runs the current code without any modification)
- a Shibboleth attribute name

2) configure Shibbolet to send the attribute we set in step 1

3) within getAffiliation() method a switch like this:
AffiliationSource affiliationSource = // read configuration
switch (affiliationSource.getType()) {
case AffiliationSource.Shibbolet:
String affiliation =
readAffiliationFromAttribute(affiliationSource.getShibbolethAttribute());
break;
case AffiliationSource.DiscoFeed:
default:
String affiliation = // run current code
break;
}

AffiliationSource has a type, which is an enum of ShibbolethAttribute
and DiscoFeed, and a shibboletAttribute (String) field, which contains
which attribute should be used.

Can you imagine this in Dataverse?

Best,
Péter

Philip Durbin <philip...@harvard.edu> ezt írta (időpont: 2019.
jún. 4., K, 21:56):

> To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CABbxx8GBDfoZJzwjK9_z20SHZ6NuT2zQyyA8xPQuRPyuxkwYww%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.



--

[Philip Durbin]

These are good ideas but please do not attempt to modify the DiscoFeed file because it is autogenerated by shibd. Harvard Dataverse and UNC Dataverse, for example, allow login from all of InCommon so https://dataverse.harvard.edu/Shibboleth.sso/DiscoFeed is quite long and ultimately based on the (filtered, Research & Scholarship category only) data from http://md.incommon.org/InCommon/InCommon-metadata.xml . The is defined in "MetadataProvider" in http://guides.dataverse.org/en/4.14/installation/shibboleth.html#shibboleth2-xml and examples are given for "Identity Federation" (e.g. InCommon) or "Specific Identity Provider(s)" which is probably a more common configuration (e.g. universities in Texas at https://dataverse.tdl.org/Shibboleth.sso/DiscoFeed ).

I like your idea of making Shibboleth support in Dataverse more configurable, more flexible. I would suggest making the smallest change possible, the smallest "diff" in a pull request to express what you mean about adding a configuration option to get the affiliation from a source other than the DiscoFeed. This initial "diff" might not get merged as-is but I and others will be in a better position to give you feedback on the idea when we have a "diff" in front of us.

I hope this makes sense. Thanks for thinking hard about this!

Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CABFhGt%3DCsE-o4R%2B%3DRJP5-r6haQWUY7x8LLWsgWpSP%3DgSKKaC5Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.