Auto Configuration Reloading Test Case for IDP

[Joshua Riffle]

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 *cacheDuration *argument
for a file-backed metadata such that it will keep reloading a file after
every duration and check for changes?


Joshua Riffle
Software Engineer
*Azusa Pacific University*


On Thu, Jan 23, 2014 at 2:05 PM, Kevin Foote <kpfoote at uoregon.edu> wrote:

> The idea is to limit the number of MetadataProviders you define in your
> relying-party.xml..
> So in practice you group your metadata into larger buckets (xml files)
> that contain more than a single RP.
>
> Generally you’ll want to load something like 3 or so MetadataProviders in
> your relying-party.xml
>
> local-rp-md.xml
> federation.xml
> external-partners.xml
>
> 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.
>
> That was the simplified nutshell version but you can find various threads
> in the archives on this practice…
>
> --------
> thanks
>  kevin.foote
>
> On Jan 23, 2014, at 1:39 PM, Joshua Riffle <jriffle at apu.edu> wrote:
>
> > Hi Peter,
> >   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?
> >
> >
> > Joshua Riffle
> > Software Engineer
> > Azusa Pacific University
> >
> >
> > On Thu, Jan 23, 2014 at 12:54 AM, Peter Schober <
> peter.schober at univie.ac.at> wrote:
> > * Joshua Riffle <jriffle at apu.edu> [2014-01-23 01:34]:
> > > Picture didn't seem to show for the Service Provider example so here
> it is
> >
> > Your complete post didn't seem to have made it to the list (I have not
> > yet looked at any attached pictures, not knowing what for).
> >
> > > On Wed, Jan 22, 2014 at 4:31 PM, Joshua Riffle <jriffle at apu.edu>
> wrote:
> > > > So I have been testing scenarios for applying configuration
> > > > changes to an Identity Provider using the automatic configuration
> > > > reloading (in service.xml) on relying-party.xml specifically. In
> > > > my use-case I tried momentarily commenting out a vanilla
> > > > Shibboleth Service Provider that I use for testing.
> >
> > For that specific issue I'd create an entry in the project's bug
> > tracker. But note that that is not a recommended configuration
> > strategy and as workarounds exist it might not be treated with high
> > priority.
> >
> > The recommended way to dynamically add, change or remove metadata
> > without restarting the container (or context) is via auto-reloading
> > metadata providers. There's no need to and you should not add a new
> > RelyingParty to relying-party.xml for each and every SP.
> >
> > So maybe this is a classic case of "It hurts when I do this".
> > -peter
> > --
> > To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> >
> > --
> > To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140123/b3803b8a/attachment.html