[Tf-aai] Practical improvement to be made to SAML metadata processing/monitoring for SPF, increasing robustness

Tue Oct 20 17:38:48 CEST 2015

Hi Sander,

I think I understand what you are trying to do, but I have similar reservations as Jozef. Of course we can all configure our SPs to give something useful and we can all start using version control on our SPs directly, but I have my slight doubts that that will happen consistently. You are essentially moving the inconsistency problem. What if I register a new email with Haka and forget to update my servers as well?

What I don't quite understand from your Estonian example is, what stops us from getting the email addresses from their official federation metadata, in this case TAAT? 

Maybe I am missing something, but automatically getting unsigned metadata directly from SPs (even with https) seems a little too flexible for my liking. In the task force meeting (and I just realise I still have to write the memo!) we talked about not registering a local SP in the local federation at all but directly to the SPF. This indeed means the SPF needs to check the Metadata carefully before passing it on to other federations, essentially doing the job of a federation. Do we want that? If I first register (or generate) my MD at home, the SPF has some assurance that the MD is of a certain quality, it at least works for the home organisation.

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: "Sander Maijers" <sander at clarin.eu>
> To: "tf-aai" <tf-aai at lists.clarin.eu>
> Sent: Tuesday, 20 October, 2015 17:36:41
> Subject: Re: [Tf-aai] Practical improvement to be made to SAML metadata processing/monitoring for SPF, increasing
> robustness

> Hi Jozef,
> 
> On Tue, Oct 20, 2015 at 4:16 PM, Jozef Misutka <misutka at ufal.mff.cuni.cz>
> wrote:
> 
>> Dear Sander,
>>
>> I see the clear advantages of your approach, but I have three comments:
>> - shibboleth SP automatically adds a warning to the metadata that cannot
>> be easily removed [1];
>>
>> <!--
>> This is example metadata only. Do *NOT* supply it as is without review,
>> and do *NOT* provide it in real time to your partners.
>>  -->
>>
>>
> I know Shibboleth or at least Scott Cantor has some opinions about this,
> without giving any support for this position. I've never seen a problem
> with the metadata generation handler. Any unknown risk originating from the
> SP's metadata generation handler would occur after a change to the
> template, and would only affect that SP, if if affects anything at all (as
> we can of course automatically check the SAML metadata on the receiving for
> basic or subtle errors, if this is really a risk).
> 
> There are crucial differences between just passing down the bare, initial
> automatically generated SAML metadata without any review and without
> providing any template of your own vs. my proposed workflow. Per-Entity
> SAML metadata, in whatever shape, is inevitable to allow SAML AAI to scale.
> See e.g.
> https://spaces.internet2.edu/display/InCCollaborate/Per-Entity+Metadata+Pilot
> .
> 
> 
>> - the SP admins can easily forget to copy the md_template.xml (shibboleth
>> sp) when upgrading to a newer version;
>>
> 
> Maybe I misunderstand, but I do not see that as a real downside. The
> metadata template is part of the normal configuration and should be in the
> same directory. It's just a matter of basic system administration skill to
> not miss one configuration file, isn't it? This kind of issue should be
> addressed in centres' deployment and configuration management processes.
> 
> 
>> - we keep a versioned metadata file which we use as the primary source (we
>> relied on the metadata generation only once) so it would require policy
>> change (for us it is easy but might be a problem for others?).
>>
> 
> You can check out the version controlled template file inside your
> configuration, or keep your whole configuration under version control, and
> no further policy change or change of internal workflow for the
> administrators would be required.
> 
> 
>> Nevertheless, we could use your approach first for automated emails to the
>> SP technical contacts that in case they changed something, they should
>> update svn metadata (icinga plugin).
>>
> 
> This can be done, but if CLARIN SPF does not take a official position on
> whether the SAML metadata at the SP should be consistent with the SAML
> metadata in its SVN, then CLARIN SPF formally has no basis to warn SP
> operators of such inconsistency. If we do take this official position, then
> we would be past a hurdle to my workflow anyways, and simply implementing
> that workflow may be more effective against less effort than setting up the
> warning system.
> 
> 
>> Best,
>> Jozef
>>
>>
>>
>> [1] http://shibboleth.net/pipermail/users/2013-February/007968.html
>>
>>
>> On 20 October 2015 at 15:31, Sander Maijers <sander at clarin.eu> wrote:
>>
>>> Hi Dieter,
>>>
>>> I have foreseen that we cannot always ingest the EntityDescriptor of each
>>> SP as-is. It is relatively simple to automatically enrich the automatically
>>> ingested EntityDescriptors with e.g. Entity Categories in a second
>>> processing step. Making some modifications to the XML data will be
>>> necessary anyway, to provide MDRPI registrar info e.g. for each SP
>>> EntityDescriptor:
>>> <md:Extensions
>>>     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
>>>     xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi">
>>>   <mdrpi:RegistrationInfo registrationAuthority="
>>> https://www.clarin.eu/spf" <https://incommon.org/>/>
>>> </md:Extensions>
>>> (This is useful and requested by e.g. Haka for downstream processing
>>> (e.g. recognizing the SPF SPs from the eduGAIN SAML metadata batch).)
>>>
>>> Furthermore, if an SP meets DP-CoCo it can attest to that by changing the
>>> SP's SAML metadata template. This entity category may be self-asserted (and
>>> should be, to reduce management overhead). The REFEDS Research and
>>> Scholarship Entity Category must, however, be assigned by a ‘registrar’. In
>>> practice, in a future scenario where all identity federations consume our
>>> SAML metadata through eduGAIN, we no longer need to keep doing that
>>> ourselves, as DFN AAI can already assign us the REFEDS R&S EC.
>>>
>>> I'm not advocating doing smart merging of two full SAML metadata sources,
>>> that would be more complex and error-prone. This functionality is already
>>> accounted for by SAML metadata generators in SP software, which is another
>>> reason not to do that ourselves.
>>>
>>> Best,
>>> Sander
>>> --
>>> *Sent as system administrator and engineer for CLARIN*
>>> *Centre Registry & Service Provider Federation* @ {centres,infra}.
>>> clarin.eu;
>>> *software engineering tools* @ {svn,trac}.clarin.eu;
>>> *identity and access management* @ {user,idp}.clarin.eu
>>> *usage statistics and service monitoring* @ stats.clarin.eu
>>>
>>> Max Planck Institute for Psycholinguistics <https://tla.mpi.nl/>,
>>> software developer
>>> personal Skype: sander.maijers | work address: Wundtlaan 1, 6525 XD,
>>> Nijmegen (NL)
>>>
>>>
>>>
>>> On Tue, Oct 20, 2015 at 2:28 PM, Dieter Van Uytvanck <dieter at clarin.eu>
>>> wrote:
>>>
>>>> On 20/10/15 14:18, Sander Maijers wrote:
>>>>
>>>> > What do you think of automatic fetching of SAML metadata from the
>>>> > SAML metadata generator endpoint of production SPs (e.g.
>>>> >
>>>> https://ekrksso.keeleressursid.ee/simplesaml/module.php/saml/sp/metadata.php/ekrk-sp
>>>> > or https://clarin.oeaw.ac.at/Shibboleth.sso/Metadata), and
>>>> > automatically importing each SP's EntityDescriptor into the SAML
>>>> > metadata batch about SPF SPs in our SVN?
>>>>
>>>> Hi Sander,
>>>>
>>>> how would this affect the manually post-edited entries (like the
>>>> CoC-link that is added)? Or do you foresee some smart merging between
>>>> the pure technical snippets automatically generated by the SP and the
>>>> full enriched SAML entries, as currently available in our SVN?
>>>>
>>>> best,
>>>> --
>>>> Dieter Van Uytvanck
>>>> Technical Director CLARIN ERIC
>>>> www.clarin.eu | tel. +31-(0)850091363 | skype: dietervu.mpi
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
> 
> 
> [Text File:ATT00001]