<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Jan 2019, at 21:24, Cantor, Scott <<a href="mailto:cantor.2@osu.edu" class="">cantor.2@osu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 1/23/19, 3:35 PM, "users on behalf of Jerry Shipman" <<a href="mailto:users-bounces@shibboleth.net" class="">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:jes59@cornell.edu" class="">jes59@cornell.edu</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""> (Or am I just completely misunderstanding how it works? I didn't do the homework.)<br class=""></blockquote><br class="">I suppose I would say that the homework is [1] and there's no substitute for testing and tuning until you get acceptable results or decide that you can't live with the risks. I assume by now the UK Fed might have recommendations on configuration for their service and that's the only one in production anywhere that I know of.<br class=""></div></div></blockquote><div><br class=""></div><div>The UKf documentation for per-entity metadata is here:</div><div><br class=""></div><div><a href="https://www.ukfederation.org.uk/content/Documents/MDQ" class="">https://www.ukfederation.org.uk/content/Documents/MDQ</a></div><div><br class=""></div><div>The UKf per-entity service is architected in a fairly similar way to the intended InCommon one, at least in the sense that per-entity documents are signed in a batch process not exposed to clients, and moved out to multiple edge servers for availability and performance. The details are different (in-house HSM rather than in-cloud, Azure not AWS, custom CDN instead of a commercial one).</div><div><br class=""></div><div><div><blockquote type="cite" class=""><div class="">On 23 Jan 2019, at 20:35, Jerry Shipman <<a href="mailto:jes59@cornell.edu" class="">jes59@cornell.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span class="" style="font-family: Monaco; float: none; display: inline !important;">It sounded like, in the per-entity-metadata world, the individual SP metadata files will be retrieved and validated as they are needed, e.g. the first time a user logs in to that SP. (then cached for a while.)</span><br class="" style="font-family: Monaco;"></div></blockquote><div><br class=""></div><div>Yes, that's correct, if you just use a simple dynamic metadata resolver configuration that refers to an MDQ endpoint, it doesn't fetch anything you don't need. That's a major part of the motivation for per-entity metadata.</div><div><br class=""></div><div>Once you do have it, there are two things the client knows: how long the metadata should be cached for (roughly, for how long to wait before it should bother looking for an updated copy) and how long the metadata is valid for (which is normally longer than the cache interval). In the UK federation case, for example, the cache duration is six hours and the validity is 14 days.</div><div><br class=""></div><div>The difference between the two is the window during which the MDQ service can be broken but the client can survive on already-fetched metadata.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><span class="" style="font-family: Monaco; float: none; display: inline !important;">And like there was correspondingly a risk that maybe if the metadata server is down or the network is flaky or something, at that moment, then the person can't log in.</span></div></blockquote></div><br class=""><div class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px; -webkit-text-decorations-in-effect: none;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""></div></span></div></div><div>Yes, if no-one has tried to access that SP since the IdP started, or no-one has accessed it for a long time, a fetch will be attempted and if that fails then that person can't log in (everyone else is still fine, of course, unlike in the aggregate case).</div><div><br class=""></div><div>The first thing to say is that the likelihood of this is very low. As was discussed in the webinar, things like AWS CloudFront have good SLAs and regularly exceed them. You need to think about how much you care about that outage coinciding with referencing a very seldom used SP.</div><div><br class=""></div><div>If you assess that to be a problem then there are a couple of possible mitigations. One would be to identify SPs which are both seldom-used and critical, and arrange to pre-fetch them as described for example in the UKf documentation.</div><div><br class=""></div><div>If you're still feeling exposed, you could think about standing up your own MDQ server. I just so happen to have written one of those based on the Shibboleth metadata aggregator framework:</div><div><br class=""></div><div><a href="https://github.com/iay/mdq-server" class="">https://github.com/iay/mdq-server</a></div><div><br class=""></div><div><a href="https://github.com/iay/mdq-server-docker" class="">https://github.com/iay/mdq-server-docker</a></div><div><br class=""></div><div>A version of this has (as was mentioned in the webinar) been running as <a href="http://mdq-beta.incommon.org" class="">mdq-beta.incommon.org</a> for the past several years. It operates by periodically grabbing the InCommon production aggregate, grinding it up into pieces and then signing those pieces on request.</div><div><br class=""></div><div>I wouldn't actually recommend this for most people; it would be hard to convince yourself that such a service would be more reliable than CloudFront. It would have _different_ risks, and perhaps there are circumstances in which it would make sense. If, for example, you wanted to generate some custom aggregates as well as serving per-entity metadata, that might be a good route.</div><div><br class=""></div></div><div class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px; -webkit-text-decorations-in-effect: none;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div class=""> -- Ian<br class=""></div><div class=""><span class="Apple-style-span" style="font-size: medium;"><br class=""></span></div></span></div></span><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>