[Tf-aai] Fwd: Update of SAML metadata about SPF SPs, including key rollover

[Sander Maijers]

See below an possibly interesting exchange with Peter Schober, known for
his critical viewpoint.



---------- Forwarded message ----------
From: Sander Maijers <sander at clarin.eu>
Date: Fri, Nov 27, 2015 at 2:51 PM
Subject: Re: Update of SAML metadata about SPF SPs, including key rollover
To: eduid at aco.net
Cc: "spf at clarin.eu" <spf at clarin.eu>


Hi Peter,

None of us @ SPF had put priority on all this discussion, so the response
is a bit late.

Maybe I can say something interesting here. But please mind that we have
limited time for discussion and maybe some face-to-face setting in which a
(friendly) debate between more pople is possible, would be a better place
to discuss policy issues like the ones you often bring up.

On Wed, Oct 21, 2015 at 8:05 PM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Sander Maijers <sander at clarin.eu> [2015-10-16 16:35]:
> > We know of the problem with the US SPs. They do not have proper privacy
> > policy in place, and I've urged them and other to resolve the matter.
> > DFN-AAI then apparently has not assigned REFEDS R&S EC, last summer
> > Wolfgang was working on supporting this EC. I will contact him to ask him
> > about the current status.
>
> DFN-AAI has more than 30 R&S SPs registered, so they seem to support
> R&S just fine (both for CLARIN and other SPs).
>

Seems like a misunderstanding on my part of your comment about R&S for our
SPs.

> We are currently working on a plan to formalize and enforce our policy,
> > already in practice, that SP operators do not register their SPs in their
> > home identity federations or other identity federations. This will
> prevent
> > the indeed irritating issue of multiple copies of the same entity in
> > eduGAIN. The only exceptions are currently a Czech SP and some Dutch SPs.
> > Both are moving in the right direction.
>
> Somewhat "naturally" I'm opposed to that idea. :)
>
> To me our copy of the CCV Metdata is the authoritative version, as it
> has been checked by us and has been amended with all the information
> we cared to amend (which is more than other copies will have).
> I claim that it will be of better quality all around, and that I have
> a good communication basis with the entity owner (all our entity
> owners, of course) sharing a federation with them.
> We also publish a MDRPS statement (referenced in that metadata) that
> will tell anyone what parts of the we checked.
>

*: Nothing stops SP operators from additionally enlisting SAML experts like
you to improve the SAML metadata about their SP. They could for instance
let thee SAML metadata about their SP pass through the local 'test'
federation, as they now do (hopefully).


> In contrast, the metadata in the SPF aggregate had weird issues in the
> past, e.g. when I looked once it included entity attributes may only
> be assigned by the registrar (REFEDS R&S), but did not have a
> registrar defined, hinting at "blind" copy&paste from other sources,
> by either the entity owner or the SPF admins.
>

We in fact consider ourselves registrar in terms of the R&S definition.
Your interpretation of 'home federation' as (non-bindingly) referred to in
that definition, is 'home *identity* federation'. Such interpretation
should be discussed between all stakeholders, certainly as you apply it to
a set of SPs that are (mostly, if not completely) exclusively operated
within the context of a single Service Provider federation, and for which
identity federations are only means to an end.


> Not even if all registrations are /only/ done by the SPF will all the
> metadata descriptors for the same entity be identical, due to
> differences in the way federations manage their entities.
>

I do not see the point of this argument. Why would SAML metadata about an
SP need to be identical across identity federations? The advantage is in
preventing or limiting concurrent modification of the SAML metadata by
multiple parties, whether or not there are still differences due to the
influence of different identity federation operators.


> (Unless the SPF becomes a full federation and metadata registrar in
> its own right. I have always thought that to be useless duplication of
> work but maybe that's still better than the current state.)
>

But what do you consider a full federation and metadata registrar?

Also the fact that one of those federations publishes a copy of an
> entity to eduGAIN does not contribute to the multiple non-identical
> copies issue, as the copy in eduGAIN would be the same as in the
> federation that registered and published it to eduGAIN.
>

It is not clear to me why you make this argument. Duplicates do not matter
much of course, see my previous comment for what does matter to us.


> But of course I'm biased thinking that we have a track record of
> registered entities, securely signed feeds, and proper validation (and
> amendment, wherever possible, according to changing community best
> practices) of all relevant data.
>

For a small and young federation, the CLARIN SPF has a great track record
as well, in those senses. But we should not let pride or ideals get in the
way of being result-oriented.


> Every federation operator doing this (registering their own entities
> and publishing them to eduGAIN where sensible) is the natural way of
> doing interfederation. The SPF should not aim at having its own
> workins depend on prohibiting entities to join their local federation
> (and eduGAIN from there).
>

Keep in mind that you are now jumping to 'prohibiting'. To the contrary,
perhaps CLARIN participants would simply agree to not do that? The wording
'depend' is also an exaggeration. Note that your argument is not more
convincing because of such strong language.


> > A list of deviation of our guidelines, including for DP CoCO EC, is at:
> >
> https://docs.google.com/spreadsheets/d/1cwg2kiPL2ubzmtw7Ffe0rbQuJpuOoklFHJ10nR3Bn_M/edit#gid=659443784
>
> Point in case (as per above): Take for example the "deviations" of the
> CCV https://clarin.oeaw.ac.at/shibboleth:
> None of these shortcomings occur in the copy in eduID.at:
> It has (and always had) the mdui:Logo (with https URL),
> mdui:DisplayName (in German and English) and mdui:Description
> elements.
> I.e., we have provided the full data, but your own copy is lacking.
>

But with this example, you paradoxically *support* the proposal to let
CLARIN SPF manage SAML metadata about SPs instead of home identity
federations, since then the SPF would have the most current version of it,
and there would be no such problem! Do consider that the actual *usage* of
this SP is via the CLARIN ecosystem. Users - who should actually be the
main focus of all our discussions - are not using it because CLARIN
provides them this service. It is not that the users are Austrian and start
using after their interest was sparked by the mere fact that ACOnet
delivers them all kinds of AAI related services. You do not instruct or
direct your members of participants to this SP. Nor are all our your IdPs
necessarily registered with eduGAIN (at least not according to your MDRPS
and Policy document) and accepting eduGAIN registered SP. In this light,
why is it reasonable that you sit on top of the most current SAML metadata
about this SP, objecting to automatically incorporating our SAML metadata
about CLARIN SPF SPs into your local SAML metadata batches?

As I wrote before*, an arrangement in which you can keep some control and
in which you can provide your expertise to the AAI workflow for the CLARIN
SPF are possible. For instance you could work with operators of new
Austrian CLARIN SPF SPs to get the SAML metadata about these SPs into your
own 'test' SAML metadata publication, before changes are pushed to the
CLARIN SPF.


> > > E.g. I could pull the metadata from
> > > https://infra.clarin.eu/aai/prod_md_about_spf_sps.xml
> > > extract out the entityIDs and add those to our whitelist for upcoming
> > > eduGAIN import. Maybe not fully automated but with notifications, so
> > > I'd still have some chance to look at the entities before injecting
> > > them into eduID.at.
> >
> > That would be very welcome. This way, I have more time left to solve
> > any issues you find for us.
>
> I'll probably write a Nagios check that notifies us of differences to
> the list of entityIDs published at
> https://infra.clarin.eu/aai/prod_md_about_spf_sps.xml


If you have written it, then you know there have been some changes since
then. :)

Best regards,
> -peter
>

Best,
Sander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clarin.eu/cgi-bin/mailman/private/tf-aai/attachments/20151214/a2b4ce5a/attachment.htm>