Auto-reload the relying-party and attribute-Resolver

[David Langenberg]

We do pretty much the same thing.  The default relying-party entry is setup
such that 99% of the SPs we federate with will be handled how we want them
to.  The other 1% get their own entries & that's only because they're
generally vendors which have some problems with encrypted
assertions/attributes and/or signatures.  I'll maybe touch
relying-party.xml once a year, if that.

Dave


On Thu, Aug 8, 2013 at 11:09 AM, David Bantz <dabantz at alaska.edu> wrote:

> Your elaboration on this recommended practice would be appreciated Peter.
>
> David Bantz
>
> On Thu, 8 Aug 2013, at 01:20 , Peter Schober <peter.schober at univie.ac.at>
> wrote:
>
> > * Nate Klingenstein <ndk at internet2.edu> [2013-08-07 18:44]:
> >>> Whenever I make  a change in config files (relying-party or
> >> attribute-Resolver), I have to do a tomcat restart to reload the
> >> files. Is there any way, it can do a auto reload?
> >>
> >> Generally, yes.
> >>
> >> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfigConfig
> >
> > Even better: Change your config/thinking in a way that it does not
> > require changes to relying-party.xml.
> >
> > (Reloading the resolver once in a while and reloading the filter more
> > often seems fine, until a time we rely on metadata alone for attribute
> > release.)
> > -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
>



-- 
David Langenberg
Identity & Access Management
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130808/67c8f688/attachment.html