<div dir="ltr">Thanks Kevin that helps a lot! I'll starting hunting through the archives, too, but I'm curious if it matters whether the metadata is in static file format or retrieved from a URL. For example, it seems that automatic reloading works just fine for InCommon metadata from a URL because it has a sort of built-in TTL... does that correlate with the <i>cacheDuration </i>argument for a file-backed metadata such that it will keep reloading a file after every duration and check for changes?<br>
</div><div class="gmail_extra"><br clear="all"><div><font face="tahoma, sans-serif"><div><font face="tahoma, sans-serif"><br></font></div>Joshua Riffle</font><div><font face="tahoma, sans-serif">Software Engineer<br></font><div>
<font color="#CC0000" face="tahoma, sans-serif"><b>Azusa Pacific University</b></font></div></div></div>
<br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 2:05 PM, Kevin Foote <span dir="ltr"><<a href="mailto:kpfoote@uoregon.edu" target="_blank">kpfoote@uoregon.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The idea is to limit the number of MetadataProviders you define in your relying-party.xml..<br>
So in practice you group your metadata into larger buckets (xml files) that contain more than a single RP.<br>
<br>
Generally you’ll want to load something like 3 or so MetadataProviders in your relying-party.xml<br>
<br>
local-rp-md.xml<br>
federation.xml<br>
external-partners.xml<br>
<br>
So if you get a new local RP you just add the md to the local-rp-md.xml file and when the usual metadata refresh happens for that file then the new RP gets picked up.<br>
<br>
That was the simplified nutshell version but you can find various threads in the archives on this practice…<br>
<br>
--------<br>
thanks<br>
<span class="HOEnZb"><font color="#888888"> kevin.foote<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Jan 23, 2014, at 1:39 PM, Joshua Riffle <<a href="mailto:jriffle@apu.edu">jriffle@apu.edu</a>> wrote:<br>
<br>
> Hi Peter,<br>
> I appreciate the best-use recommendation of auto-reloading metadata providers and not creating a new RelyingParty for each SP, but haven't caught onto this recommendation or how to implement in the documentation. Do you have links anywhere I could follow up on?<br>
><br>
><br>
> Joshua Riffle<br>
> Software Engineer<br>
> Azusa Pacific University<br>
><br>
><br>
> On Thu, Jan 23, 2014 at 12:54 AM, Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br>
> * Joshua Riffle <<a href="mailto:jriffle@apu.edu">jriffle@apu.edu</a>> [2014-01-23 01:34]:<br>
> > Picture didn't seem to show for the Service Provider example so here it is<br>
><br>
> Your complete post didn't seem to have made it to the list (I have not<br>
> yet looked at any attached pictures, not knowing what for).<br>
><br>
> > On Wed, Jan 22, 2014 at 4:31 PM, Joshua Riffle <<a href="mailto:jriffle@apu.edu">jriffle@apu.edu</a>> wrote:<br>
> > > So I have been testing scenarios for applying configuration<br>
> > > changes to an Identity Provider using the automatic configuration<br>
> > > reloading (in service.xml) on relying-party.xml specifically. In<br>
> > > my use-case I tried momentarily commenting out a vanilla<br>
> > > Shibboleth Service Provider that I use for testing.<br>
><br>
> For that specific issue I'd create an entry in the project's bug<br>
> tracker. But note that that is not a recommended configuration<br>
> strategy and as workarounds exist it might not be treated with high<br>
> priority.<br>
><br>
> The recommended way to dynamically add, change or remove metadata<br>
> without restarting the container (or context) is via auto-reloading<br>
> metadata providers. There's no need to and you should not add a new<br>
> RelyingParty to relying-party.xml for each and every SP.<br>
><br>
> So maybe this is a classic case of "It hurts when I do this".<br>
> -peter<br>
> --<br>
> To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
><br>
> --<br>
> To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>