Campus Shibboleth Metadata Management Tool

Local Campus Metadata Management Tool

One of the items identified early in our discussions on what is needed to make Shibboleth easier to deploy and use effectively on campus was the notion of a campus local metadata management tool.  Many schools have created local solutions and many others manage local metadata by hand.  Our question here is what would be the requirements for a campus federation local metadata management tool.  If such a tool looks useful, does it make sense for TIER to adopt or create one.

 The focus for a TIER Campus Metadata Management tool would be to provide automation for the common, general campus use case and will not delve into specialized needs that will not be experienced at most campuses.  The tool should focus on Shibboleth SPs only but also provide a mechanism to ingest pre-existing entity xml as part of its build cycle.

Requirements

1. End Users

1. Enable campus users to authenticate using Shibboleth and request that their SP be added to the campus metadata distribution.

1. Simple web form to prompt the SP operator for standard/simplified information.  Included with the default web form is text that explains the needed elements and where to get the information.

2. Error checking on the entered data. 

2. The ability for the identity that created the entry and designates to edit the entry (including the list of designates).

3. The ability for the identity that created the entry and designates to delete the entry.

4. Ability to check on the processing status of the request, including the ability for pure self-service - i.e., automatic addition to the metadata.

2. System Operators

1. The ability for campus system operators to edit any metadata entry.

2. The ability for campus system operators to approve/reject requests.

3. The ability for campus system operators to, perhaps manually, directly edit the metadata for an entity.

3. General

1. Handle only the case of the addition of SP metadata.

2. Send email to End Users whenever the data for an entity that they own is modified.

3. Be trivially simple to containerize, install, and operate.

4. Keep track of previous versions of entity metadata

5. Options to publish metadata (a) on a regular cycle, (b) after testing by a sysadmin, or (c) in semi-real time after a new record is submitted.

6. Support for regular review and signoff by entity owner

7. Ability to know that sets of entities are linked (e.g., production and test)

4. Information Requested

1. Contact information / Dept information

2. Certificate(s)

3. Virtual host(s) / SAML endpoints

4. MDUI extension info

5. Requested attributes and justification for sensitive attributes

6. Software implementation details (text box or a few standard answers plus “other”)