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

[Sander Maijers]

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