An open discussion list for topics related to the eduGAIN interfederation service.

[Jozef Misutka <misutka AT ufal.mff.cuni.cz>]

On 3 March 2017 at 15:52, Chris Phillips <Chris.Phillips AT canarie.ca> wrote:

This thread has some^H^H^H^H a lot of interesting things:

1. This technique appears to be not an n by m problem but an N by M by #
of instances of these tools problem and that is to say, not very scalable
and brute force like.

It's like every one who has a phone number calling every other phone
number to see if it works.
Every day.

I get the desire to survey what's working and what doesn't and very much
support the eduGAIN CC in it's current form.
It's a good litmus test to poll a few URLs and provides a thumbnail view
with sufficient accuracy for now.

What's not sufficient about it (besides 'it's not exhaustive!')?

What CC says is if an IdP login screen can be successfully reached or not using two particular SPs.

If there is a problem, it is very likely a problem for more SPs.

If there is not a problem, it does not mean your SP with that IdP works because of that IdPs special settings, metadata problems in federations (like for us) etc.

I do not understand your analogy here. We are on the internet, anyone can scrape web sites automatically without blocking the other end (in most cases).

I really hope that each and every IdPs scale far more than to 1500 (# of SPs) requests per day (one in 60 seconds).

Moreover, it does not need to be done every day.

 

2.Are there cases of other internet scale components that do this? I'm
skeptical that there are and they probably don¹t do it for a reason.

If we look at other things like DNS servers, routers, web servers, TOR, or
other internet components or protocols, this behaviour/assessment doesn't
really manifest itself there -- does it? Why not and why would we pursue
that if other internet scale components don't have this?
If they do, I would like to hear the success stories please.

We are looking at the monitoring of IdP login screen differently. 

But to answer your question a web server/web page is an internet scale component and quite a lot web servers/web pages are being monitored from multiple locations regularly.

Because you have "only" 1500 customers (SPs), monitoring from each of them once a day/week is really doable.

 

3. Has anyone thought about how this will be interpreted as malicious
traffic for nefarious purposes OR cases of unintended consequences if you
attempt to poll all sites working at all IdPs?

If you scrape thousands of public web pages, is that malicious traffic?

We are talking about about simple http redirects here (what is done in the background is not of our concern like it is not our problem that a web page needs to access a database).

If I am not mistaken, CC checks if you end up with an IdP login page after going to e.g., 

https://lindat.mff.cuni.cz/Shibboleth.sso/Login?SAMLDS=1&target=https://lindat.mff.cuni.cz/repository/xmlui/shibboleth-login&entityID=https%3A%2F%2Faccess-check.edugain.org%2Fsimplesaml%2Fsaml2%2Fidp%2Fmetadata.php

nothing more and nothing less (that is our SP and edugAIN access check IdP)

Jozef

 

Case in point: When HeartBleed occurred, the notion of polling for such an
exposure was risky and borderline, if not 'illegal' in some jurisdictions.
 Help me understand why probing functioning Sps around the globe in all
IdPs doesn't tread in this area or get ensnared in this problem.

Another datapoint is another tool that can do some interesting things --
Ripe Atlas probes.  There's a reason that they have limited functionality.
It's not that it's technically not possible to do more, it very much is
possible to do a LOT more, but policy wise not prudent to have a device
that could result in highly improper data being retrieved and in turn
cause an unaware operator grief.

There are jurisdictions that have severe consequences for just visiting
sites. Demonstrating that very probability could be 'very bad'.
(Remember, there is no such thing as not making a mistake in configuration
-- they happen, this means they happen on the global stage and not just
locally.)

4. How sustainable is doing this, including the curation and data storage
over time?

Storage and compute is free right? ;)

5. Privacy and security considerations.

There's a difference between 'does this look healthy' and posting an
entire medical chart on something.  How would one manage this?


I really like the ECC (as well as the eduGAIN validations tools at
technical.edugain.org) and how both have evolved to add value to our
operations. I really can't operate in a global context without them.  Hats
off to creators and sustainers of the tools and really appreciate that
they are there. If this type activity is being seriously contemplated, I
hope we can have some dialogue on the above points before leaping into the
unknown waters because it's not just a technical feasibility question.

C

On 2017-03-03, 6:50 AM, "Leif Johansson" <leifj AT sunet.se> wrote:

>
>> this and adapt ECCS. As you say, this would however mean that each IdP
>> currently would be hammered more than a thousand requests per day
>
>good!
>
>> because m=1466 as of today :-) I know at lesat from our Danish
>> colleagues that this might ruin their statistics if not handles
>>properly.
>>
>
>just add an extension to the authnrequest saying this is a probe
>
>> Another option could be that the ECCS REST/JSON API is extended to check
>> a particular IdP-SP combination and return the check results.
>>
>
>this would introduce too much delay for the applications I've been
>thinking about - its more important that the API returns quickly
>then that the test is 100% fresh IMO
>
>>
>> @Marco (ECCS lead developer): Feel free to add/comment on what you think
>> of this.
>>
>> Best Regards
>> Lukas
>>
>> [1] https://technical.edugain.org/eccs/
>>     https://wiki.edugain.org/EduGAIN_Connectivity_Check
>>
>