[Tf-aai] Blacklisting IdPs: A proposal

Mon Nov 25 17:16:49 CET 2019

Hi Martin and all,

> for example what happens if an IdP provides eppn to SPs, but not mail and another SP needs mail and the IdP does not react? Should that be a reason for blacklisting?

I would be careful to “mark in red” IdPs for this reason, because:
1. There are some CLARIN SPs that do not need “email” nor we currently specify “email” as a mandatory SPF attribute [1].
When a user of one of these SPs arrives to https://discovery.clarin.eu and sees her institutions marked in red, this can potentially demotivate the user to login. While in truth that IdP-SP combination will work just fine.

2.IdPs might release certain attributes to one CLARIN SP and not to the other (due to white/blacklisting on their side). So making an IdP as “red” because this IdP did not release attribute X to SP Y, does not say much about which attributes are released by this same IdP to a different CLARIN SP. (This has happened before)

3. From the above I think the only way is to do the “mark in red" blacklisting for IdP<->SP pairs, rather than only for IdPs. This way the IdP won’t show up in red when discovery.clarin.eu is invoked by a different SP.

4. Any of these solutions implies development time on the side of discovery.clarin.eu which has to be checked against availability.

> Change the "If you cannot find..." text as follows:

I also like the idea of a [I cannot login]  button.
I also agree with the approach of "first try to get the Uni to react and if that fails offer the CLARIN account”, for the reason you mention (I add one bellow). This is also our current policy at CLARIN ERIC. We could change this, but to do so we should first evaluate the capacity and workflows on the side of the management of the CLARIN account requests. This is done by the Utrecht office but I am not aware of how much capacity is currently assigned to it, though I suspect not much.
Also mind some other issues, e.g.:  CLARIN accounts are not regular checked for validity of the initial conditions and virtually never expire. If a user requests an account while a member of a University and then moves on to a private company, we have no mechanism in place to find it out and act accordingly.

> ---++ The process in detail

I agree with your process. One remark is that many situations like this actually start in the middle of point 4 and then do not have your point 1. i.e.
1. clarin.eu contacts the IdP directly after a user report directly to spf at clarin.eu (the address mentioned in https://discovery.clarin.eu/) and which most users use to report login problems. For SPs using https://discovery.clarin.eu ,it is hardly the SP operator who is contacted by the user in case of a login problem.
Should we still have both 2 weeks periods in this case? Or should we forget about the initial one?

Regards,
André

[1] - https://www.clarin.eu/content/attributes-service-provider-federation

----
André Moreira
CLARIN ERIC
https://www.clarin.eu

> On 5 Nov 2019, at 18:36, Martin Matthiesen <martin.matthiesen at csc.fi> wrote:
> 
> Hi,
> 
> Here's my suggestion for blacklisting IdPs. Some details need to be discussed, for example what happens if an IdP provides eppn to SPs, but not mail and another SP needs mail and the IdP does not react? Should that be a reason for blacklisting?
> 
> I wonder whether we should mark IdPs as "blacklisted" in the Discovery Service, but still make login via them possible for those SPs that work with the Attribute Set provided.
> 
> Concretely, the blacklisting should be accessible from:
> 
> https://discovery.clarin.eu
> 
> Change the "If you cannot find..." text as follows:
> 
> "If you cannot find your organisation in the list below, this maybe for two reasons: Your home organisation does not provide a login option or we have blacklisted your home organisation, because your home organisation does not provide CLARIN member services with sufficient information about users that try to log in, for example the user's email adress. Please check our list of blacklisted IdPs for more information about the blacklisting process.
> 
> If you cannot login for reasons stated above, please select the clarin.eu website account and use your CLARIN website credentials. If you don't have such credentials you can register an account here."
> 
> 
> The "list of blacklisted IdPs"
> 
> ---+ IdPs currently blacklisted by CLARIN
> 
> * IdP One
> * IdP Two
> 
> (maybe searchable)
> 
> ---+ CLARIN's blacklisting process
> 
> The CLARIN Service Provider Federation was created to ensure cross-border login to CLARIN services. If an IdP after repeated requests refuses the release of attributes to CLARIN services this IdP is blacklisted, since it is effectively not usable with CLARIN services. CLARIN also considers considerable administrative hurdles, like filling out complex paperwork which is not in English as a reason to blacklist and IdP.
> 
> ---++ The process in detail
> 
> 1. An SP operator requests Attribute Release from an IdP on behalf of CLARIN and states CLARIN's support for the Data Protection Code of Conduct as well as Research and Scholarship and cc's spf at clarin.eu.
> 2. The IdP either
> 2.1. does not react or
> 2.2. demands a complex application procedure to allow Attribute Release
> 3. The SP operator waits a week and
> 2.1. sends a reminder or
> 2.2. requests a simpler application procedure.
> 4. The SP operator requests that clarin.eu contacts the IdP directly and informs about a possible blacklisting if the issue is not resolved within 2 weeks.
> 5. If no resolution is found after 2 weeks the IdP is blacklisted.
> 
> Comments?
> 
> Martin
> 
> --
> Martin Matthiesen
> CSC - Tieteen tietotekniikan keskus
> CSC - IT Center for Science
> PL 405, 02101 Espoo, Finland
> +358 9 457 2376, martin.matthiesen at csc.fi
> Public key : https://pgp.mit.edu/pks/lookup?op=get&search=0x74B12876FD890704
> Fingerprint: AA25 6F56 5C9A 8B42 009F  BA70 74B1 2876 FD89 0704
> _______________________________________________
> Tf-aai mailing list
> Tf-aai at lists.clarin.eu
> https://lists.clarin.eu/cgi-bin/mailman/listinfo/tf-aai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.clarin.eu/cgi-bin/mailman/private/tf-aai/attachments/20191125/95719512/attachment.sig>