[Tf-aai] Blacklisting IdPs: A proposal

Mon Nov 25 18:29:04 CET 2019

Hi André,

You raise a good point, and maybe we should change the marking in red to a red question mark or similar and explain that logins to SP X, Y Z are currently not supported.
Since the Discovery Service knows what SP is invoking it it could taylor the list, but that is again development work. And frankly, a question mark would make users of other services aware that their home organisation is not supportive of CLARIN.

I think some constraints emerge:

- user friendlyness: We don't want to overpower users with AAI issues
- coding: we need a simple solution that does not require extensive coding.

Maybe the "I cannot login" is indeed the simplest solution. Users should click that if they have issues loging in and check whether their home org is listed. Maybe the DS can mark prolematic IdPs slightly by changing the font and or the background colour ever so subtly.

Martin

----- Original Message -----
> From: "André Moreira" <andre at clarin.eu>
> To: "Martin Matthiesen" <martin.matthiesen at csc.fi>
> Cc: "tf-aai" <tf-aai at lists.clarin.eu>
> Sent: Monday, 25 November, 2019 18:16:49
> Subject: Re: [Tf-aai] Blacklisting IdPs: A proposal

> 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