search

DataverseNO / dataverse

Open source research data repository software
http://dataverse.org
Other
0 stars 0 forks source link

Authentication support for Feide #3

Open philippconzett opened 3 years ago

philippconzett commented 3 years ago

We want users to be able to authenticate with Feide.

Alternatively, we could use eduGAIN, which includes Feide. @4tikhonov has also mentioned EGI. What are the advantages of EGI compared to eduGAIN?

For background information about issues with authentication in DataverseNO, see this Dataverse GitHub issue: https://github.com/IQSS/dataverse/issues/4334.

raymondandreassen commented 3 years ago

Hi, just to answer a question I received by mail.

Feide is web. Web works perfectly from Azure. So yes, a service in Azure could use Feide as user authentication. How to enable it? I am not sure if a Feide service is locked to a certain IP address, however the returnurl parameter must be valid. This can be done by changing DNS or the login form request a different return url (also, must be valid and accepted by all parties).

Just as a note on the side, UIT Feide will soon use Azure AD as backend. (I guess by 1/1/2022). This means nothing to your project and users outside UIT (choosing a different organisation).

Se also: Unit om Feide "Det er mulig å knytte tjenesten til innlogging gjennom Feide."

philippconzett commented 3 years ago

Thanks, @raymondandreassen

@Louis-wr @4tikhonov It would be good to get this up and running before our nest meeting on September 22. If I remember this correctly, the Feide integration we currently are using in DataverseNO is based on Shibboleth. I guess we need to switch the Feide integration to OAuth if we also want to enable authentication through ORCID (which is based on OAuth), because one cannot use two different protocols (e.g. Shibboleth and OAuth) in the same Dataverse installation?

In our test instance, we need to use test Feide (test-idP), as we currently do at test.dataverse.no (see https://test.dataverse.no/loginpage.xhtml;jsessionid=e3aae346ee2922cb6d0ec7db79a6?redirectPage=%2Fdataverse.xhtml). Once we have this in place, ITA / @raymondandreassen needs to approve our test instance to use test Feide for UiT affiliates.

So, we need to

Please complete/edit this list as needed.

Please have a look at the different authentication integration options in Dataverse as described in the installation guide (https://guides.dataverse.org/en/latest/installation/):

For background information about issues with authentication in DataverseNO, see this Dataverse GitHub issue: https://github.com/IQSS/dataverse/issues/4334.

philippconzett commented 3 years ago

We will also need to fix the problems we have with our current Feide integration. Only a part of the metadata is provided correctly to Dataverse. For example, instead of the affiliation of the user (e.g. UiT The Arctic University of Norway), “Feide” is provided as affiliation.

philippconzett commented 3 years ago

Answer from Stig Wennevold (ITA/UiT):

The feide-login for dataverse.no is set up differently from a typical service, which is probably why you have issues with the return values. I would guess the intention is to offer choice of federations at some later stage ? We will probably need to involve Uninett in the debugging, but if you could outline what you are trying to achieve long term and and example of the data returned after logon it will be helpful.

philippconzett commented 3 years ago

Ideally, we want to use Feide through a globally federated service like eduGAIN. (@4tikhonov has also mentioned EGI. What are the advantages of EGI compared to eduGAIN?) I see that the CLARINO repository (based on DSpace) at UiB (cf. https://repo.clarino.uib.no/xmlui/) uses a federated service (eduGAIN?) combined with Uninet's DiscoJuice. Not sure whether this is still maintained by Uninett or if there are any other solution we should opt for.

A common odd thing with Feide in federated login services like eduGAIN is that the system usually asks you to search for your institution, but as a user from Norway, you won't get any hit on your institution, because "Feide" would be the only relevant "institution" in your case.

philippconzett commented 3 years ago

Stig Wennevold (ITA/UiT):

What attributes do you see as returned from Feide after logon ? When I try to logon to dataverse; Feide claims it will release amongst other things this info about me:

Distinguished name (DN) of person's home organization: dc=uit,dc=no Distinguished name (DN) of the person's home organizational unit: ou=RING,ou=ITA,ou=FAdm,ou=UiT,cn=organization,dc=uit,dc=no Distinguished name (DN) of person's primary Organizational Unit: ou=RING,ou=ITA,ou=FAdm,ou=UiT,cn=organization,dc=uit,dc=no Home organization domain name: uit.no

This is just a small subset of the org-info that could be released and from the way the service is registered in Feide I see nothing that should prevent more attrs being returned. Do you ask for a specific list of attrs in the code dataverse uses to connect to Feide ? As far as I cant tell you should be able to get all attrs listed below; maybe som of them would be useful :

(I’ve not cc’ed everyone on this email, if after at bit of back and forth we find something useful you could put a summary in git as needed )

• Affiliation at home organization eduPersonAffiliation • Primary affiliation at home organization eduPersonPrimaryAffiliation • Affiliation and institution at home organization eduPersonScopedAffiliation • Unique identifier of organizational unit eduPersonOrgUnitDN:norEduOrgUnitUniqueIdentifier • List of schools feideSchoolList • Names of organizational units eduPersonOrgUnitDN:ou • Email address of organizational unit eduPersonOrgUnitDN:mail • Organization number eduPersonOrgDN:norEduOrgNIN • Realm of home organization schacHomeOrganization • Name of home organization eduPersonOrgDN:o • Legal name of home organization eduPersonOrgDN:eduOrgLegalName • Organization email address eduPersonOrgDN:mail • Common name of organizational unit eduPersonOrgUnitDN:cn • Distinguished name of organizational unit eduPersonOrgUnitDN • Distinguished name of primary organizational unit eduPersonPrimaryOrgUnitDN • Postal address of educational unit eduPersonOrgUnitDN:postalAddress • Telephone number of organizational unit eduPersonOrgUnitDN:telephoneNumber • Acronym for the organizational unit eduPersonOrgUnitDN:norEduOrgAcronym • Common name of home organization eduPersonOrgDN:cn • Distinguished name of home organization eduPersonOrgDN • Unique identifier of home organization eduPersonOrgDN:norEduOrgUniqueIdentifier • Postal address of home organization eduPersonOrgDN:postalAddress • Telephone number of home organization eduPersonOrgDN:telephoneNumber • Home page of home organization eduPersonOrgDN:eduOrgHomePageURI • Acronym for the educational institution eduPersonOrgDN:norEduOrgAcronym • Version of norEdu specification of home organization eduPersonOrgDN:norEduOrgSchemaVersion

philippconzett commented 3 years ago

As the user information is set up currently in the Dataverse software, we only need the following information

philippconzett commented 3 years ago

I suggest we just start with implementing eduGAIN. I guess they have a test environment. @Louis-wr could you figure that out?

philippconzett commented 3 years ago

Stig Wennevold (ITA/UiT):

Whether the value “feide” is incorrect depends on which attribute you use to try and find the home institution today; but in either case the info you need is encoded in a number of the attributes that may be passed, and even indirectly in some that the logon process claim are released.

If eduPersonOrg:o is available to the code It should contain the name directly; if not something like eduPersonOrgUnitDN will contain dc=uit,dc=no which could be used via a lookup to find the name (this is inelegant, scales badly and seems unnecessary however)

probably the easiest way to get further is to have whoever wrote / maintains the dataverse code look at how the attrs currently used are fetched and try to see what others are available (ideally in a test version, or very carefully in prod 😉 )

philippconzett commented 3 years ago

@Louis-wr Can you figure out what we need to have in place to test eduGAIN? Slava shared these links in our meeting today: https://guides.dataverse.org/en/latest/installation/oidc.html OpenID https://openid.net/specs/openid-connect-federation-1_0.html

Louis-wr commented 3 years ago

Feide Oauth configuration : curl -X POST -H 'Content-type: application/json; charset=utf-8' --upload-file ./feide.json http://localhost:8080/api/admin/authenticationProviders feide.json

{
    "id":"feide",
    "factoryAlias":"oidc",
    "title":"Feide",
    "subtitle":"",
    "factoryData":"type: oidc | issuer: https://auth.dataporten.no | clientId: <clientId> | clientSecret: <clientSecret>",
    "enabled":true
}
Louis-wr commented 3 years ago

desired feide attributes:

userinfo-name givenName sn

userid-feide) uid

groups-org eduPersonOrgDN:eduOrgLegalName eduPersonPrimaryAffiliation eduPersonPrimaryOrgUnitDN

documentation: https://docs.feide.no/reference/schema/attributegroups/index.html https://docs.feide.no/reference/schema/noredu/noredu_ch03.html#eduorglegalname

Louis-wr commented 3 years ago

Currently the dataverseNO is not communicating properly with feide and is not getting the correct attributes. Suggested remediation: Using the groups api, not the userinfo endpoint https://docs.feide.no/reference/oauth_oidc/groups_data_model.html, in particular the examples at https://docs.feide.no/reference/oauth_oidc/groups_data_model.html#example-1-employee-in-uninett https://docs.feide.no/reference/apis/groups_api.html

GET request toward https://groups-api.dataporten.no/groups/ with a valid token