Auto Configuration Reloading Test Case for IDP

[Joshua Riffle]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140123/76c1c556/attachment.html