Page History

Background

One if the traditional impediments to smaller school adoption of the Shibboleth IdP has been its XML-based configuration management.  Recent work for the TIER version of Shibboleth has expanded the ability to control Shibboleth’s configuration via entity attributes.  These enhancements will become part of the Shibboleth distribution with the next release. The goal for the work was to enable entity attribute-based control of 80% or more of the routine day-to-day configuration changes made by administrators.  

The Shibboleth enhancements were designed to facilitate the implementation of a GUI to manage configuration while, to the greatest extent possible, minimize the interactions between the GUI and Shibboleth itself.  The GUI’s only required role is to manage the metadata filters section of the metadata-providers file.  An optional set of features would include fuller management of metadata features.

Application Requirements

The GUI is expected to be a simple web application that can be trivially deployed into many environments.  One required deployment scenario is the TIER Shibboleth VM appliance itself.  Schools may choose other local or cloud deployments.  Basic application functionality includes:

1. Provide a mechanism to create new and edit existing entity records
   1. Display a screen containing all supported per-entity configuration
   2. In the case where an entity is already defined, display the current values, otherwise display a set of default values.
   3. Provide an organized display enabling easy selection/deselection of features/attributes by name.  Provide a simple description of functionality for each item listed.
2. Provide mechanisms to list configured entities, delete, and duplicate existing records.
3. Provide mechanisms to import and export entity records.
4. Provide a mechanism to generate filters and update the metadata-providers file
   1. Sanity check the contents as part of build
   2. Archive the previous version of the file
   3. Enable review before publishing
5. Maintain an optional comments section for each entity configuration
6. Maintain a log all transactions
7. Retain some small number of previous versions of the configuration for each entity
8. Support common templates
   1. Ability to manage groups of relying parties, effectively applying the same properties to each relying party
   2. Ability to start with a template, and add/subtract elements; retaining the template link for future changes
9. Simple user authorization support is required
   1. Binary, against REMOTE_USER, via a user maintained file is sufficient.
10. Software updates must be trivially deployable while retaining existing school configurations.  Localizations, if any, should be easy to retain.
11. Data integrity in the face of multiple users is required.
12. Ability to coexist with other school-developed filters.  The tool must insert its configuration into a specific placeholder in the metadata-providers file.

Technical Infrastructure Preferences

The technical infrastructure should be designed to minimize deployment and operational requirements.  The application will be used occasionally as opposed to continually so trade-offs to optimize ease of deployment and operation over anything related to performance are appropriate.

1. Ease of Configuration
   1. The addition of new elements should not require code changes
   2. Changes to screen language should not require code changes
   3. Simple tooling is desired.  Tooling subject to approval by TIER.
2. Ease of Operation
   1. The decision on it to use a database or a simple filesystem scheme should be part of the design document.  The goal is to minimize, within reason, operational needs for schools running the application.
   2. Basic installation automation (scripting)
   3. Deployment and, if needed, usage documentation.
   4. Security
      1. Even though deployments are expected to be private and not public facing, programming to protect against standard web application security risks is required.

Development Support

1. TIER Shibboleth VM distribution for testing
   1. A standard TIER appliance running the updated Shibboleth code
2. Initial naming table
   1. A table that maps names to functions.
3. A few handcrafted example metadata-filter statements
4. Assistance, as needed, with any changes required by the incorporation of the TIER modifications into the Shibboleth distribution.
5. Assistance with testing