Auto Configuration Reloading Test Case for IDP

[Kevin Foote]

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