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

[Jozef Misutka]

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.
 -->

- the SP admins can easily forget to copy the md_template.xml (shibboleth
sp) when upgrading to a newer version;
- 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?).

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).

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/778583dd/attachment.htm>