[Tf-aai] Filtering suspicious IdPs in CLARIN SPF

[Martin Matthiesen]

Hello, 

I would like to propose a definition below. 

> From: "Jozef Mišutka" <misutka at ufal.mff.cuni.cz>
> To: "spf" <spf at clarin.eu>
> Cc: "tf-aai" <tf-aai at lists.clarin.eu>, "Willem Elbers" <willem at clarin.eu>
> Sent: Tuesday, 18 April, 2017 13:29:16
> Subject: [Tf-aai] Filtering suspicious IdPs in CLARIN SPF

> Hi Andre,
> (cc-ing tf-aai@ too for comments)

> we should have a more formal and public way how to blacklist IdPs from CLARIN
> SPF. We have the tools, so we really need only minor changes and better
> documentation. In reality, this will be very rare but should be documented
> nevertheless.

> The flow is like this:

> 1. User authenticates to one of CLARIN SPF SPs
> a) we have information about the IdP in [
> https://lindat.mff.cuni.cz/services/aaggreg/ |
> https://lindat.mff.cuni.cz/services/aaggreg/ ] so we can check if it looks
> suspicious or not;
> b) different web applications inform about new users (e.g., clarin-dspace sends
> an email) so we can even check if the attributes seem ok.
> ACTION POINT (optional): email new IdPs from attribute aggregator

An email list would be good, I guess, like "new-idps at lists.clarin.eu". I personally would not sign up for that list, because I assume that IdPs that falsely assert eduPersonAffiliation=member as outlined below to be virtually non-existent. That is the only authorization we would directly use from IdPs. 
IdPs that otherwise only authenticate are not a problem for us, since we have to authorize manually anyway and can treat users on a case-by-case basis, an example is again outlined below. 

> 2. In 1a) or 1b) someone finds a suspicious IdP and CLARIN SPF should be
> notified about it
> QUESTION: what is the best/preferred way to notify CLARIN SPF - trac? email?

I suggest Trac. In a way such an IdP would be an anomaly that might also need prioritasation. Trac would also keep, well, track of decisions. 

> 3. CLARIN evaluates if that IdP is really problematic or not
> ACTION POINT: define a problematic/non problematic IdP e.g., problematic IdP is
> the one that does not validate its users more that by sending emails
> ACTION POINT: make this definition public (will be decided what is the best way
> [1])

I think we need to distinguish 2 things: IdPs with low level of assurance and IdPs with assumed non-academic users. 

We have such an IdP in Haka, called Eduuni ("E-Work" in Finnish): http://id.eduuni.fi/signup/?lang=en. You can get an "eduuni" ID with LinkedIn/Facebook, but you can also use Haka and even eduGAIN, in which case high value attributes are passed through. 

I would specifically not want to blacklist such an IdP Clarin-wide, since such IdPs can be valuable for authentication, especially from non-academic users like citizen scientists. We actually have such a case, a translator who would like to be able to see her own work as deposited: http://urn.fi/urn:nbn:fi:lb-2016110901. 
We can authenticate her via Eduuni and authorize her via lbr.csc.fi for her own works. We would use this for Citizen Science projects as well. 

We decided at some point in Kielipankki that ePA=member is a good enough criterion to grant access to CLARIN ACA resources, accepting some grey areas. After all university libraries allow non-academic users to see IP-restricted content at the premises. Since Eduuni only sends affiliation information if the user has authenticated via a university account, we don't have a problem. We can authorize the user manually via lbr.csc.fi. We only have a problem with IdPs that set affiliation=member (or worse: student, faculty) for users that clearly are not part of the academic community. CSC's own IdP is a border case, we set "member" as well for our staff. 

Proposal: 

I would like to clearly blacklist only IdPs that assert eduPersonAffiliation=member, even though the user is not member of an academic institution. See http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonAffiliation: 

> "Member" is intended to include faculty, staff, student, and other persons with a full set of basic privileges that go with membership in the university community (e.g., they are given institutional calendar privileges, library privileges and/or vpn accounts). It could be glossed as "member in good standing of the university 
> community." 

Incidentally our very own Clarin IdP does not abide by that definition. 

I understand the use case in Lindat is different and Lindat might want to exclude IdPs like "Eduuni" or at least put extra scrutiny on them. Maybe we could have a traffic light system where we only include "green" IdPs in the SPF feed. Or we go for "green"/"yellow". 
Deliberately excluded services would be listed separately and marked. Services like Eduuni would be marked as "yellow" and rogue IdPs as outlined above in "red". 

Martin 

> 4. SPF will add this IdP into the filters
> QUESTION: is filtering (blacklisting) of IdPs in CLARIN SPF happening before
> they are published to [ https://infra.clarin.eu/aai/prod_md_about_spf_idps.xml
> | https://infra.clarin.eu/aai/prod_md_about_spf_idps.xml ] and if so then
> where?
> ACTION POINT: make filtered IdPs public (will be decided what is the best way
> [1])

Yes, they should be public, already for the reason that SPF SPs that also support eduGAIN need to blacklist them separately. 

Martin 

> To all, please feel free to comment, share practices etc. At LINDAT, we have the
> following page
> [ https://lindat.mff.cuni.cz/en/how-do-i-sign-up |
> https://lindat.mff.cuni.cz/en/how-do-i-sign-up ] (see section Supported
> Organisations)
> Best,
> Jozef

> [1] In my todo list is still to prepare a short CLARIN AAI requirements document
> where we could add it and publish that document.

> [Plain text file:ATT00001]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clarin.eu/cgi-bin/mailman/private/tf-aai/attachments/20170418/5765049c/attachment.htm>