Page History

...

One if the traditional impediments to smaller school adoption of the Shibboleth IdP has been its XML-based configuration management.   Recent work by the Shibboleth team for the TIER version of Shibboleth has expanded the ability to control Shibboleth’s the IdP configuration via entity attributes .  ("tags") associated with the SAML metadata of a relying party. These enhancements will become part of the Shibboleth distribution with the next release. The goal for the work was has been to enable entity attributemetadata-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 embedded within the metadata-providers.xml file .  An to apply designated entity attributes at runtime. An optional set of features would include fuller encompass more complete management of metadata featuressources as well as the associated filters.

The Shibboleth documentation on this feature in the form in which it will be made available in V3.4 is here.

Application Requirements

...

1. Provide a mechanism to create new and edit existing entity recordsattributes:
   
   1. Display a screen containing all supported per-entity configurationattributes.
   2. In the case where an entity attribute is already defined, display the current values, otherwise display a set of default maintain the possible 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 entitiescreate, view, edit, delete, and duplicate existing recordsassociations between supported entity attributes and the entities to which they should be associated. Associations should be possible on the basis of at least:
   1. Specific relying parties.
   2. Ad-hoc collections of specific relying parties.
   3. Relying parties that possess existing entity attribute name/value pairs (e.g. entity categories such as the Research and Scholarship designation).
   4. Optionally, relying parties for which a Java scriptlet evaluates successfully.
3. Provide mechanisms to import and export entity recordsassociations.
4. Provide a mechanism to generate the appropriate filters and update the metadata-providers.xml file:
   1. Sanity check the contents as part of buildthe generation process.
   2. Archive the previous version of the file.
   3. Enable review before publishing.
5. Maintain an optional comments section for each entity configurationset of associations.
6. Maintain a log all transactions.
7. Retain some small number of previous versions of the configuration for each entityassociation.
8. Support common templates
9. Ability to manage groups of relying parties, effectively applying the same properties to each relying party
Ability to start with a template, and add/subtract elements; retaining the template link for future changesof collections of entity attribute properties to apply, and the ability to attach such templates by reference or value (the former maintaining the link such that changes to the template automatically apply to each association of the template).
10. Simple user authorization support is requiredBinary, against . Support for REMOTE_USER , via a user matched against a deployer-maintained file or table of authorized users is sufficient.
11. Software updates must be trivially deployable while retaining existing school configurations.  Localizations, if any, should be easy to retain
12. Internationalization of the UI must be possible, but actual translations are not required.
13. Data integrity in the face of multiple users interacting with the application is required.
14. Ability to coexist with other school-developed filters.  The ; the tool must insert its configuration into a specific placeholder(s) in the metadata-providers.xml 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 entity attribute properties should not require code changes
   2. Changes to screen UI language should not require code changes, and ideally should be based on standard HTTP language negotiation.
   3. Simple platform requirements and tooling is desired.  Tooling , specifics subject to approval by TIER. Components beyond those already required by the Shibboleth IdP should be minimized.
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 The goal is to minimize, within reason, operational needs for schools running the application.
   2. Basic installation automation (scripting)and upgrade support and automation are required.
   3. Deployment and, if needed, usage documentation are required.
   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.

...

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. An Initial entity attribute set based on the convention and supported properties outlined in the documentation.
4. Handcrafted example metadata filters demonstrating how to express the required associations.A few handcrafted example metadata-filter statements
5. Assistance, as needed, with any changes required by the incorporation of the TIER modifications into the Shibboleth distribution.
6. Assistance with testing.