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

Martin Matthiesen martin.matthiesen at csc.fi
Thu Oct 22 12:37:23 CEST 2015 

Hello,

I add Krista Liin. Krista, I will add you to the TF mailing list, my appologies you missed parts of this discussion.

----- Original Message -----
> From: "Sander Maijers" <sander at clarin.eu>
> To: "Martin" <martin.matthiesen at csc.fi>
> Cc: "tf-aai" <tf-aai at lists.clarin.eu>
> Sent: Wednesday, 21 October, 2015 16:35:59
> Subject: Re: [Tf-aai] Practical improvement to be made to SAML metadata processing/monitoring for SPF, increasing
> robustness

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

Is it? If you don't need it for testing?
 
> 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.

Why would they not? Do you have an example?

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

I am not so sure whether centralisation is a good idea here. I think the pros and cons need to be thoroughly discussed. After all we are dependent on the Home Organisations trust in us.

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

Since the SP MD is for testing purposes, to me the answer is clear.

>   It appears
>   that you prioritize your identity federation, other SP operators may
>   instead prioritize their SP's configuration (e.g. the Estonian SP).

I am not too aware of the estonian model, I am afraid. But it is the first time that I hear the SP MD is used directly.

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

Ok, not nice, with that we have to live. But for Home Organisations that do have standards you at least have an idea on what to expect. With your model you have to know the SP Operator.

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

True, but how does that get better by weakening the overall QA?

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

Yes this happens but does not go away with your proposal.

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

I opt for SVN. At least you have version control for sure in place.

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

I am not too concerned about tampering, more about unintended metadata changes (even technical ones) that force updates throughout SPF.
However not-too-userfriendly GUIs like Haka's RR are, they at least produce somewhat consistent Metadata. Going to raw SP mode is a step backwards for many.

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

Hmm, so you still want to go through SVN even though SVN is no longer the source? 

Well, when discussing making eduGAIN a requirement for CLARIN SPs (where we overlooked that DFN-AAI exports them there anyway) one argument was to not increase the burden on SP operators by yet another requirement. 

I would like to keep things local. If Haka is not happy with Kielipankki's metadata I would not want to discuss that through the SPF but directly with them. After all most of my users are definitely not from the SPF but from Haka, and I guess that is true for most of us. But I don't want to be too negative here. Should we have a task force meeting on this? I personally think that we are creating about the same amount of problems for us that we want to solve.

Martin

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

More information about the Tf-aai mailing list