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

Sander Maijers sander at clarin.eu
Wed Oct 21 15:35:59 CEST 2015 

Hi Martin,

On Tue, Oct 20, 2015 at 5:38 PM, Martin Matthiesen <martin.matthiesen at csc.fi
> wrote:

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

I see that it requires some (small) amount of mental adaptation if you are
not used to keeping the SAML metadata up-to-date within your SP's
configuration. It is indeed a sin to forget updating your SP's
configuration. ;)

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

   - We have been in contact with TAAT, but waiting on them to get a
   connection. We do not monitor their metadata, and actually it wouldn't be
   more practical than the kind of system I'm proposing, to monitor each
   identity federation's metadata for changed contacts automatically. Though
   we do have the automatic diffs already at https://centres.clarin.eu/spf.
   - SPs are not necessarily self-registered with any home identity
   federation. In fact another change that has been discussed among TF-AAI
   members as you point out, is to consistently let CLARIN manage all
   registration at identity federations. (I hope we will follow a path toward
   centralization of management of cross-federation SAML metadata
   distribution, together with decentralization of managing the contents of
   this SAML metadata.)
   - Finally, if there is an inconsistency in e.g. technical contacts
   specified between the SAML metadata provided by the SP itself vs. by its
   ‘home’ identity federation, which one would be authoritative? It appears
   that you prioritize your identity federation, other SP operators may
   instead prioritize their SP's configuration (e.g. the Estonian SP).

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

Depending for QA on the home identity federation of SP, implies variable
QA. Variable QA is insufficient QA, if it can dip below our own standards.
And it can, for instance, Belnet seems to not do any checking at all. Every
identity federation has its own rules, which may clash. When an SP
operators first jumps through hoops for his or her home identity
federation, then this gives them a false sense of security, that their SAML
metadata are now okay for cross-federation distribution. By not
centralizing SAML metadata distribution a effort can be made fruitlessly by
SP operators, if the SPF then asks them to change their SAML metadata again
after they first had to deal with their home identity federation's rules.

Whenever we talk about security, there's a risk of becoming oblivious to
reality with all the threats and protections that go through our minds.
Let's think about this very concretely. What is more secure? Accepting SVN
commits automatically from 168 developer accounts - that are not monitored
or expired currently - or fetching SAML metadata from an SP itself
automatically, authenticated and protected against tampering by TLS and (if
desired) additional techniques? Also, what would be the point of tampering
with the SAML metadata about an SP when can already tamper with the SP's
website itself? If one wants the phish users into logging in on a fake SP
website, the SAML metadata is not the first place to attack. And I fail to
imagine other kinds of worthwhile attacks.

Many identity federations that CLARIN SPF is connected with have processes
in place to check the quality of SAML metadata. If something fishy ends up
with them, surely they would spot it. And that is just a realistic ‘extra’
layer of security in addition to our own manual monitoring of all commits,
which we can put a procedure for in place, the monitoring probes that Jozef
and I are going to work on, and our own already existent automatic QA
validation
<https://docs.google.com/spreadsheets/d/1cwg2kiPL2ubzmtw7Ffe0rbQuJpuOoklFHJ10nR3Bn_M/edit?usp=sharing>.
All of these checks apply to both automatic ingestion of the SAML metadata
and manual commits, as both would still go through e.g. the SVN.

Regards,
> Martin
>

Best,
Sander

--
> 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]
> _______________________________________________
> 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/20151021/a4721887/attachment.htm>

More information about the Tf-aai mailing list