Page History

...

1. General
   1. The tool only needs to handle the use case of Shibboleth SP metadata.
   2. The tool will send email to the user making a change and the listed contacts whenever the data for an entity is modified.
   3. The tool should be trivially simple to containerize, install, brand, and operate.
   4. The tool will provide some mechanism to track of previous versions of entity metadata.  This requirement can be met by either literally archiving old metadata files or logging every change made with the date, time, and login identifier of the user making the change.
   5. The tool will be configurable 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. (nice to have) The tool will provide support for regular service provider review process where a user authenticates and signs off that the entity record is up to date and still needed.
   7. (nice to have) Ability to know that sets of entities are linked (e.g., production and test).  This requirement is not well specified and should be considered for a future version.
   8. The application should be architected to not preclude the addition of a future simple REST API that enables the creation, modification, and deletion of entity records.
   9. (Nice to have) The application validates the generated metadata file with a tool such as Oxygen to verify schema/syntax.
2. Architecture
   1. While other deployment models are anticipated, the most common model will be inside a Docker container, effectively behind a campus Shibboleth SP.  Deployment using a Shibboleth SP should be assumed, though not required.
   2. Authentication and authorization data will be acquired external to the application and made available to the application in its environment.  The application will use the identity and authorization attributes from the server environment or headers, including but not limited to REMOTE_USER. Access control must be possible through arbitrary combinations of attributes and values.
      1. The application should be architected and delivered using pluggable Authentication and Authorization modules.  The interface between these modules and the application should be as simple as practical to meet the application’s needs.
      2. Per-entity authorization data is maintained and consumed by these modules.
   3. User interface components are not hard coded into the application.
3. Application Behavior with the default, provided AuthN/AuthZ modules (i.e., the out-of-the box behavior of the application)
   1. Campus administrators will have the ability to use some combination of simple user identity (eppn), groups, entitlements, etc., depending on their infrastructure, to control access to entity records.
   2. The default, provided, AuthN/Z modules will:
      1. Obtain authnz data from the environment
      2. Via a simple configuration mechanism that can be a web interface, a script to set database values, or a flat file, provide the campus administrator with the ability to configure access control for entity metadata based on a list of attributes.
         1. If any of these attributes has a value that matches the attribute data stored with the entity’s metadata, access to the record is granted.
         2. For clarification, one way to implement this feature would be to store name/value pairs with the entity metadata record.  If the user for the current transaction matches any of these stored name/value pairs, they are authorized to manage the record.
      3. Via a simple configuration mechanism that can be a web interface, a script to set database values, or a flat file., provide the campus administrator with the ability to specify a list of name/value pairs (e.g., EPPNs, groups, etc.) for administrative access.
      4. Users with administrative access have the ability to edit any/all entity records
   3. Log messages should always include the environment’s configured user value.
4. Data Management
   1. The application is free to store is data using any reasonable mechanism.  For example, a standard SQL database could work well for this application.  Simply using the filesystem to store blobs that can be parsed could also work well for this application.
   2. Whatever database/file-system mechanism is used, it needs to support simple backups.  These backups do not need to be part of the application.

...