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: Peter Schober <peter.schober AT univie.ac.at>
  • To: edugain-discuss AT geant.net
  • Subject: Re: [eduGAIN-discuss] Tool to monitor which IdP consumes your SP's metadata
  • Date: Sun, 29 Jun 2014 16:12:36 +0200
  • Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>
  • Organization: ACOnet

* Nicole Harris <harris AT terena.org> [2014-06-29 13:04]:
> We se to be putting a hell of a lot of effort in to creating rules
> which basically say how metadata can be used on one hand, and then
> saying it doesn't matter on another. This makes no sense to me.

Not sure what all those rules about how metadata can be used you keep
referring to are. I know SWAMID has some, the UKf might. eduGAIN
doesn't today (i.e., we removed them), ACOnet doesn't have any. Not
sure about all other federations. So no idea what you're getting at.

But I'll gladly (mis-)use this discussion to to in fact speak up for
rules about use (or non-use) of eduGAIN metadata, tough:
As I've learned very recently some eduGAIN member federations do not
in fact provide their members with eduGAIN metadata themself (i.e.,
they do not aggregate data from the MDA and re-sign and re-publish it
to their consituency), but instead point (end) entity owners who need
to interfederate their services to the eduGAIN MDS itself.

That has at least 3 problems, IMO:
* Trust: entity owners having joined one federation have no
reason to trust in the MDS signing key, so that comes down to either
simply using the MDS aggregate and not checking its signature, or
blindly downloading a signing key and using that for signatures.
Whereas federations may have a multitude of support channels to help
their constituency to securely bootstap their md signing key once.
* Resilience: The current MDS is not designed to be queried from end
entities the world over. samlbits.org helps here, of course, but
only if you use it (D'oh!), i.e. not for those pulling from
mds.edugain.org
* Operational complexity for the eduGAIN-OT: So far should the OT ever
decide to perform a signing key rollover it has to coordinate this
with the eduGAIN member federations. But with end entities now also
consuming the MDS directly (not mistakenly, but as part of what
their home federation told them to do) the OT would need to
coodinate the key rollover with possibly many unknown-to-them entity
owners, or risk breakage of "eduGAIN" for all those entities.

So /if/ one wanted to make rules on how the eduGAIN metadata is to be
used (not that anyone called for that, AFAIU) I'd propose to make
re-distributing the job of the eduGAIN participating federation.
-peter





Archive powered by MHonArc 2.6.19.

Top of Page