Authentication to OTA failed for user from University of Kentucky

[martin.wynne@bodleian.ox.ac.uk]

A user from the University of Kentucky, USA, failed to authenticate at ​https://ota.bodleian.ox.ac.uk/, receiving the error message that the home institution did not send the required information.

[martin.wynne@bodleian.ox.ac.uk]

The user has been in touch again. He will contact local IT at the University of Kentucky, but we would be interested to know if CLARIN can shed any light on the problem.

[André Moreira]

Hi Martin. We need more information. At what stage does the error happen? After or before inserting credentials and clicking "login". It sounds like it is after. Assuming so, we could do a ​SAML trace to see if the attributes your SP needs are being released. But this has to be done by a person with an account in this IdP.
My guess is the IdP administrator has to configure the IdP to release the attributes we need to our SPs. Ideally they do this based on the "clarin-member" entity category that all our SPs carry. If they do it based on the entityID of your SP, you SP will work but all other clarin SP will remain failing.

For your reference, we normally contact them with an email similar to this:

Subject: Attributes missing from [IdP in question]
Dear _____:

On behalf of one of the Service Providers from CLARIN Service Provider Federation (SPF) [1] 
we would like to inform you that users from your home organisation tried to access a protected
service or resource but were unable to do so because your Identity Provider has not released
all the mandatory attributes.

All the Service Providers in the CLARIN SPF are:
1) implementing the GÉANT Data Protection Code of Conduct [2];
2) are members of the REFEDS Research and Scholarship Entity Category [3];
3) are CLARIN members and have the http://clarin.eu/category/clarin-member Entity
Category which you can use for filtering.

Therefore, we kindly ask you to implement a filter releasing the required attributes to all
CLARIN SPF members.The latest authentication attempt was to:
SP entityID=http://sp.vs1.corpora.uni-hamburg.de
Attributes released:


Please, see the recommendation from the DFN federation which attributes to
release to CLARIN SPF SPs and how to do it:
https://wiki.aai.dfn.de/de:shibidp3attrfilter#freigabe_der_wichtigsten_attribute_fuer_clarin-sps
or see the CLARIN's attribute profile described at
https://www.clarin.eu/content/attributes-service-provider-federation .

Kind Regards,
XXX

[1] https://www.clarin.eu/ and https://www.clarin.eu/content/service-provider-federation
[2] http://geant3plus.archive.geant.net/uri/dataprotection-code-of-conduct/V1/Pages/default.aspx
[3] https://refeds.org/category/research-and-scholarship

[martin.wynne@bodleian.ox.ac.uk]

This appears to have been resolved. Many thanks for your help. Below is the message sent from the user (who I had asked to contact his local IT):

Dear Martin,

The team here provided the following information earlier today:

---

This service was not setup on our identity provider to provide logins, which is why there was an error generated. They pulled our information from our InCommon? federation but nobody had ever asked us to set this up on our end to complete the relying party trust. Based on information provided and some research, this relying party trust has now been setup and tested to be working. If you experience issues connecting, you may need to clear browser cookies.

---

I have tested it in the meantime and found it to now be working.

Thanks to you and everyone else on your side for your help in getting me connected!

Mark