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

[Sander Maijers]

Hi all,

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?

Practical context: there recently was a case where the Estonian SP had not
updated the technical contact in the SVN, so all messages about issues
reached a past employee instead of the current. It took some time for them
to alert me of this. This has again confirmed to me that I should pick up
an earlier idea to make sure that SAML metadata at the SP side and in the
SVN is always consistent.

Advantages:

   1. This would improve robustness: SPs must be configured at least as
   well as their are in the SVN now as the metadata about their SP as
   registered with identity federations will be directly derived from their
   own ‘feed’.
   2. Some procedures, e.g. key rollover as recently done by UFAL, will be
   more automated and again with less chance of errors. Shorter turnaround
   time. They would just need to manage the public keys at the SP side.
   3. It would encourage SP operators to configure their SP better: to use
   the SAML metadata template. It would make it more attractive to SPs to
   properly specify the UI texts, logo's etc. as it will no longer require
   them to get and use a CLARIN developer account and Subversion.
   4. Less risks when compared manually copy-pasting the SAML metadata to
   the batch in the SVN: e.g. w.r.t. well-formedness errors.

Of course, though the proposal is straightforward and does not cost a lot
of time to realize, it cannot be implemented for each SP at once. We can
limit this to SPs that meet all of these conditions:

   1. Have a working SP status page as recorded in the Centre Registry
   (e.g. https://lindat.mff.cuni.cz/secure/shib_test.pl). This makes sure
   we can monitor whether an SP is e.g. down for maintenance to control
   warnings coming from the automated job tries to fetch its SAML metadata
   feed.
   2. Have a consistent SAML metadata generator endpoint output, the same
   in content as the EntityDescriptor currently recorded in the SVN, for some
   definition of ‘the same’. This is a manual, one-time ‘pre-flight’ check. We
   would also need to communicate this with SP operators. It would be very
   helpful in this regard is the AAI taskforce would put out an easy and
   convincing position document describing this change of workflow.

As a sidenote, signing the generated metadata by each SP itself will not be
practical in this alternative workflow (unless your configure the endpoint
to be shielded with some access control rules) as one is theoretically able
to overload/DoS the SP if it has the sign the metadata on the fly at each
HTTP request. But this is not a blocking problem, as:

   1. Current EntityDescriptors in the SPF batches (and originally in the
   SVN) are not signed themselves, because this does not work well if we sign
   the whole batch (PyFF bugs) and prevents us from altering the SAML metadata
   in the SVN (sometimes quick fixes are helpful). Anyone who compromises an
   SVN account can also compromise the SPF metadata, which means we have
   limited protect already. Therefore not at all letting SPs sign the SAML
   metadata about it is the way to go, for now.
   2. SAML metadata would be fetched over https URLs only, so manipulation
   would not be trivial. Additional security can be realized with standard
   solutions using DNSSEC and public key pinning
   <https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning> if
   this is desired.
   3. There is no technical reason why Shibboleth SP could not be improved
   to do the signing only *once *per mutation of its metadata. They seem to
   be aware of the issue. Not sure if this is an issue at all with
   SimpleSAMLphp.

I would like to hear back from you if you have any thoughts or objections,
whether we can explicitly decide for or against the change and also
how/when/by whom the document or /spf page describing such a changed
workflow would be writtern.

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