Administration tools for Shibboleth?

[Jim Fox]

We use a web app and some local authorization apis to provide
self-serve and automatic update of local metadata (for SPs that
are not in InCommon), and attribute release policies.

We have a DNS 'ownership' API that lets us know who 'owns' a
particular DNS name.  Any UW person can enter or update metadata
for any entity id as long as she 'owns' the DNS parts of the entity
id and all consumer endpoints.  The local metadata file is copied
to each idp system and reloaded by the idp periodically.  We don't
have to intervene at all.

Each 'owner' of an entity id, in local or InCommon metadata, can
also use the site to request attributes.  In that case an authorized
administrator, also using the web app, approves the request and a
new release policy file gets written.  This is also periodically
picked up by each idp and reloaded.

We don't hand edit any files.

Jim



>>>
>>> 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).
>