[Tf-aai] Blacklisting IdPs: A proposal

Mon Nov 25 08:33:23 CET 2019

On Mon, 25 Nov 2019 at 07:39, Martin Matthiesen <martin.matthiesen at csc.fi>
wrote:

> Hi Jozef,
>
> Thanks for the feedback! Some comments below.
>
> ------------------------------
>
> *From: *"Jozef Mišutka" <misutka at ufal.mff.cuni.cz>
> *To: *"Martin Matthiesen" <martin.matthiesen at csc.fi>
> *Cc: *"tf-aai" <tf-aai at lists.clarin.eu>
> *Sent: *Friday, 22 November, 2019 10:09:30
> *Subject: *Re: [Tf-aai] Blacklisting IdPs: A proposal
>
>
> On Tue, 19 Nov 2019 at 17:11, Martin Matthiesen <martin.matthiesen at csc.fi>
> wrote:
>
>> Dear Taskforce,
>>
>> I'd like some feedback on the proposal, also positive comments are
>> appreciated. This issue will be discussed on the next SCCTC VC 11.12.
>>
>> Regards,
>> 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
>>
>> ----- Original Message -----
>> > From: "Martin Matthiesen" <martin.matthiesen at csc.fi>
>> > To: "tf-aai" <tf-aai at lists.clarin.eu>
>> > Sent: Tuesday, 5 November, 2019 19:36:19
>> > Subject: [Tf-aai] Blacklisting IdPs: A proposal
>>
>> > 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?
>>
>
> Firstly, thank you for the proposal Martin.
>
> We should distinguish 2 cases in blacklisting. Firstly, those that are a
> security risk (e.g., those that allow for unverified users) and those that
> do have issues with attribute release.
>
> Security villains:
> - do not include in the feed
> - hence, not included in discovery
> - marginal priority: mention it somewhere
>
> Yes, I did not cover this case, I considered it solved.
>
>
> Attribute release villains:
> - include in the feed
> - include in discovery with red flag/background/logo of a villain with a
> warning that using it might result in failed login (not because of our
> problem) and a link pointing to (see below)
> - medium priority: mention it somewhere
>
> I also wondered about a red flag directly in the Feed. If that is possibe
> it should be preferred.
>
>
> Nobody will read long text on https://discovery.clarin.eu/, I would put
> there a big button - [I cannot login] that will go to a new page describing
> the issues.
>
> Agreed.
>
> I would put your text there, the list of villains but rephrase it with the
> following notes:
> - I suppose most users will go for low hanging fruit = CLARIN IdP rather
> than bother with the University so that should be the first option (we are
> here primarily for the users and not to fight AAI battles)
>
> In a way I agree and then again I think the users need to fight part of
> the AAI battles (and they have). My approach has been to first try to get
> the Uni to react and if that fails offer the CLARIN account. This is
> slowing down the first user but if successful speeds up the access for all
> subsequent users one from the same organisation.
>
> - not in SPF is not equally bad as attribute release and moreover, the
> user can do more (theoretically) with attribute release
>
> This one I don't quite understand, my parser fails :) Could you elaborate
> what you mean?
>
>
:)

At the moment, IdPs are not in SPF because of several reasons. One of them
is that they are not in the proper feeds.
Furthermore, in this proposal, some IdPs will not be "fully" in SPF because
of known attribute release problems.
My comment was about distinguishing the causes.
If the IdP is not in SPF, there is very little our user can do - avoid
details.
If the IdP has attribute release issues, our user might nag the admins and
make it work - add details.

However, I would still make the CLARIN IdP the first choice.

jm

>
> I suggest to create a google doc that can be commented with the above text.
>
> That is a good idea, I'll try to set that up.
>
> Martin
>
>
> Best,
> Jozef
>
>
>
>> >
>> > 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
>> _______________________________________________
>> Tf-aai mailing list
>> Tf-aai at lists.clarin.eu
>> https://lists.clarin.eu/cgi-bin/mailman/listinfo/tf-aai
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clarin.eu/cgi-bin/mailman/private/tf-aai/attachments/20191125/f72b06df/attachment.htm>