Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] Tool to monitor which IdP consumes your SP's metadata

edugain-discuss AT lists.geant.org

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

List archive

Re: [eduGAIN-discuss] Tool to monitor which IdP consumes your SP's metadata


Chronological Thread 
  • From: Lukas Hämmerle <lukas.haemmerle AT switch.ch>
  • To: edugain-discuss AT geant.net
  • Subject: Re: [eduGAIN-discuss] Tool to monitor which IdP consumes your SP's metadata
  • Date: Wed, 02 Jul 2014 13:41:33 +0200
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>
  • Organization: SWITCH

>> Personally I am in favor and would support introducing a metadata
>> monitoring check tool of the kind like weblicht because it would help
>> increasing eduGAIN's overall service quality (as perceived by the end
>> user).
> Hmmmm, end-users should NOT be aware of eduGAIN so should never consider
> a service quality problem with eduGAIN.

True, end-user is a confusing and probaly wrong term I used. I should
have said SP operator (which is kind of an end-user of eduGAIN too).

Service operators are the ones who benefit most from eduGAIN just after
the end user (e.g. a student). So, we should ensure that their
perception of eduGAIN is good and they are happy :-)

What has however happened and still happens is that service operators of
a new/potential eduGAIN service test access to the/a service to see if a
user (via eduGAIN) from IdP X can access their service. If they then
notice that for a considerable number of organisations they get an error
from the IdP of the selected organisation, this probably does not raise
their opinion on eduGAIN as a service. I don't know how much this still
is true but when I last just made this check myself a few months ago,
there were quite some cases where the IdP apparently did not have loaded
eduGAIN metadata.


> For them, failure to login is
> most likely to be associated with their institution or the service, or
> possibly for some countries the federation. Or blaming Shibboleth
> because of the firebird of doom. If end users are saying eduGAIN is
> broken, we've done something wrong.

Yes, but eventually blame falls back to:
* the service (they probably are aware that they use eduGAIN metadata)
* the user's organisation (ok, it's probably their fault)
* the federation (they often get paid by the organisations)

In all three cases the blame then could falls back to eduGAIN, which
basically relies on these three user groups.

Similar things for eduroam. If users complain about "eduroam" on twitter
or facebook, who in the end suffers? The institution or country operator
whose fault it is or eduroam as a whole service?


> It might be worth having a more general
> discussion about the strategic direction for eduGAIN and whether
> participants want eduGAIN to remain something that is just about secure
> metadata exchange or to add features that increasingly make it look like
> it wants to be a confederation.

That is a discussion that is certainly worth having. So, I would support
that.


> Overall I'd be really supportive of a simple monitoring tool that could
> be used by federations, but I think the responsibility for running and
> using the tool should be at the federation-level.

How about offering the monitoring tool in a way where a federation could
"opt-out", which then would not monitor the IdPs of that federation, or
as I suggested be made aware themselves that one of their entities
probably is not consuming eduGAIN metadata. That way not all federations
would have to build/deploy/run such a tool themselves.


> It is something that
> is on the REFEDS to-do list along with other fed-lab type activities,
> but at the moment we don't really have the resources for that.

If REFEDS lacks financial resource one option could be to develop such a
tool (shouldn't be rocket science) in GEANT primarily for eduGAIN and
then release the source code for public use.

Besides weblicht, we already have a similar tool that initiates
federated logins to monitor the availability of SWITCHaai IdPs. Adapting
the source code to shape it to a slightly different purpose wouldn't be
hard.


Best Regards
Lukas

--
SWITCH
Lukas Hämmerle, Central Solutions
GÉANT Project Task Leader "Enabling Users"
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle AT switch.ch, http://www.switch.ch





Archive powered by MHonArc 2.6.19.

Top of Page