Administration tools for Shibboleth?

[Garick Hamlin]

On Wed, Mar 06, 2013 at 05:23:03PM +0100, Peter Schober wrote:
> * David Gersic <dgersic at niu.edu> [2013-03-06 16:37]:
> > >>> On 3/5/2013 at 07:32 PM, "Erdos, Marlena" <marlena_erdos at harvard.edu> wrote: 
> > > Hi Shib Users,
> > > 
> > > Are you using a tool to administer your IdP? If so, my colleagues and I
> > > would love to hear about it.
> > 
> > What's to administer? I set up the IdP. It runs. There's not much
> > else it needs to have done to it as far as administration goes.
> 
> Well, scalable attribute release is an issue for many, and
> hand-enabling new SPs does not scale well. Not enabling severly
> reduces the stuff people have access to.
> Having config autoreloading in place for pulling in changed resolver
> or filter configs is not common (but available in the software), as
> are HA/clustered approaches, so making /any/ config change will cause
> outages and may require "maintenance windows". That in turn does not
> increase the willingness or frequency of config changes or software
> updates. Same thing for branding the IdP pages (which is solved in
> both the OSU login handler and the v3 IdP).

We use a staging process here it is a combination of mod_proxy_ajp,
make, and git and two tomcats and some custom code to control the 
routing of requests for staging.  I login to a testing app which will divert
my traffic to the staging IdP.  I make the changes, commit them, and install to
staging, restart staging.  Test several applications, then install the changes
on production.  There are some limitations, but it works well in practice.

We also have two production IdPs so I can switch the secondary IdP while
restarting the primary.  All this is complicated to set up originally, but the
workflow is worth it.

Metadata is handled differently than configuration, but it also can be staged.

This works very well for us, but its not really a generic enough solution to
to package up.

Garick