Change History (9)

comment:1 Changed 7 years ago by Dieter Van Uytvanck

Owner: changed from Dieter Van Uytvanck to André Moreira
Status: newassigned

comment:2 Changed 7 years ago by Martin Matthiesen

Some questions:
The IDP is in the SPF because of the UK Federation and/or Swamid, right?
The problem is not that we do not trust the authentication part? We do trust that the IDP's users are who they claim to be. I always understood that we use all IDPs in the SPF implicitly for authentication: The user is an academic one, because IDPs in the SPF are from academic istitutions. I think we should have a broader view and accept different levels of assurance. My prediction is that in a few years we might need to serve citizen scientists and have solutions to securely identify them.

But, I'd be open to blacklist non-academic IDPs like the one here for now in the SPF.

comment:3 Changed 7 years ago by André Moreira

Component: AAIAAI IdP Blacklist
Keywords: blacklist aai spf added

comment:4 Changed 7 years ago by Dieter Van Uytvanck

The metadata says <mdui:Description xml:lang="en">Login service for Unicon Employees</mdui:Description> so I think it is clear we should blacklist this one.

At a certain point we might want to have a more philiosphical discussion about whether we should exclude non-academic IdPs? but for now we will follow-up the existing policy of doing so.

comment:5 Changed 7 years ago by André Moreira

Since the registration authority for this IdP is 'https://incommon.org' this IdP is not included in our metadata feed. Please see:
https://infra.clarin.eu/aai/prod_md_about_spf_idps.xml

So the question is why is (was) the metadata of this IdP part of the metadata used by the ufal? Either the registration authority changed meanwhile, or ufal is consuming some extra metadata feed (than
https://infra.clarin.eu/aai/prod_md_about_spf_idps.xml) which includes this IdP.

Perhaps Jozef Mišutka can provide more information on that?

comment:6 Changed 7 years ago by Jozef Mišutka

Yes, LINDAT/CLARIN uses also eduGAIN feed. But before I created this issue, I checked using https://met.refeds.org/met/entity/https%253A%252F%252Fidp.unicon.net%252Fidp%252Fshibboleth/ that it is part of one of CLARIN SPF members namely UK Federation.

So the process of SPF via eduGAIN should be re-visited.

comment:7 Changed 7 years ago by Dieter Van Uytvanck

I do not see a reasonable alternative to using the Registration Authority from the eduGAIN metadata feed. In the UK's federation stream too, the registration authority is In Common.

Similar cases are eg the university of Oklahoma - it is in the UK federation too according to the METS site (edugain site itself says otherwise). I do not see any reason to include it into the SPF.

comment:8 Changed 7 years ago by André Moreira

As much as I can see the METS reports that both (unicon and the university of Oklahoma) IdPs are included (visible) in the aggregated UK federation feed.
But the feed (and METS) also states that these IdPs are not coming from the UK federation itself, Registration authority: https://incommon.org by opposition to Registration authority: http://ukfederation.org.uk (e.g. University of London).
I think this is right since we want to include the IdPs coming from the UK federation and not all the IdPs the UK federation decides to aggregate in their feed.

comment:9 Changed 7 years ago by Martin Matthiesen

I also think we would need to add the information to our documentation that SPs should not rely on the federation feed but check the registrars if needed.

Note: See TracTickets for help on using tickets.