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

Tue Oct 20 16:36:41 CEST 2015

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clarin.eu/cgi-bin/mailman/private/tf-aai/attachments/20151020/03628c9a/attachment.htm>