...

1. After deployment, the "My Metadata" screen is initially empty.
2. With Using an "Add Role" button (we might rename it if a better suggestion arises) button, the user can select one of the following: SAML IdP, OIDC OP, SAML SP, OIDC RP.
3. Regardless of what is the selected role, the user can set up a Display Name and a Logo for the chosen role.
4. If the SAML IdP role is selected, a checklist of supported entity categories will be available:
   
   1. Research & Scholarship
   2. Anonymous Access (v2)
   3. Pseudonymous Access (v2)
   4. Personalised Access (v2)
5. If the SAML SP role is selected, the following settings/attributes are available:
   
   1. Research & Scholarship
   2. Code of Conduct

...

1. On the metadata management screen, the user presses "Add remote entity metadataRemote Entity Metadata."
2. The available options depend on the roles configured:
   
   1. If the instance has the SAML IdP role, the user can add downloaded SAML SP metadata as XML from XML a file or a URL to download.
   2. If the instance has the OIDC OP role, the user can add a redirect URI, name, and description (the instance provisions the client ID and client secret).
   3. If the instance has the SAML SP role, the user can add SAML IdP metadata.
   4. If the instance has the OIDC RP role, the user can add an OP.

...

• Step back/forward during config changes (step-by-step wizard for adding a new entity/item)? Scenarios, like proxy, could be set up the same way.
  
• Should metadata Metadata should feed into SSP and SaToSa configurations, or should we limit the MVP to one for the MVPplatform, e.g. SSP?
  
• Add/remove/update entity metadata to participated federation(s), or at least let the user know what should be notified?
• Could remote entities be offered in the GUI based on federation metadata?
  

...

Features: What about notifying the changed status to other known related entities? Or notify user that known connected entities may be affected, offering shortcuts to their configuration/relationships editing.

Configure proxy mode

Context: If you added at least one of (SAML IdP, OIDC OP) and one of (SAML SP, OIDC RP), then you can act as a proxy. In this case, a configuration option that was previously unavailable ("grey") becomes available as 'Proxy configurationConfiguration.'
Here, you can add identity and profile attribute mappings.

Features: Is proxying between SAML and OIDC for a later version beyond the MVP? Also, what would be a level of control over SAML/OIDC associations, since SaToSa is doing some things on its own.

Edit data sources and data release (not MVP)

...

1. On the Configuration screen, the user adds a data source:
   1. SQL
   2. LDAP
   3. Other...
2. The user adds connection data for the data source.
3. The user adds attribute mappings for the data source, e.g., DB field → attribute name.

User story format

"Initial setup"

As a

System Administrator

I want to

Set up the initial identity roles and metadata for the newly installed instance, so that the instance can participate in one or more federations as either a Service Provider (SP/RP), Identity Provider (IdP/OP), or both.

Description:

Upon completion of the installation process, the system instance must be configured to participate in one or more federations. These federations may include SAML federations, a collection of OpenID Connect (OIDC) parties, or internal organizational federations. The instance can assume the role of a SAML Service Provider (SP), SAML Identity Provider (IdP), OIDC Relying Party (RP), OIDC OpenID Provider (OP), or a combination of these roles.

Acceptance Criteria:

1. Initial Screen State:

   • After deployment, the "My Metadata" screen should be displayed with no pre-configured roles or metadata.

2. Add Role Button:

   • A button labeled "Add Role" should be available on the "My Metadata" screen. This button may be renamed based on better suggestions for clarity.
   • When the "Add Role" button is clicked, the user should be presented with a selection of roles:
     • SAML Identity Provider (SAML IdP)
     • OIDC OpenID Provider (OIDC OP)
     • SAML Service Provider (SAML SP)
     • OIDC Relying Party (OIDC RP)

3. Role Configuration:

   • Upon selecting any of the roles, the user should be able to configure the following general attributes:
     • Display Name: A user-defined name that will represent this role within the federation.
     • Logo: An optional logo image that visually represents the role in the federation.

4. SAML IdP Role Configuration:

   • If the user selects the SAML IdP role, they should be presented with a checklist of supported entity categories to choose from:
     • Research & Scholarship
     • Anonymous Access (v2)
     • Pseudonymous Access (v2)
     • Personalized Access (v2)

5. SAML SP Role Configuration:

   • If the user selects the SAML SP role, they should be provided with the option to configure the following settings/attributes:
     • Research & Scholarship
     • Code of Conduct

Notes:

• The user interface should be intuitive and guide the user through the process of role selection and configuration.
• The roles and their configurations should be saved and reflected in the "My Metadata" screen after the setup is completed.
• Future updates may include additional roles or settings based on evolving federation requirements.

"Adding metadata"

Information architecture

• Dashboard

  • Overview of metadata management status.
  • Quick access to recent activities and common tasks.
• Configuration
  • Configuration of the local instance not related to remote entities.
    
    • Attribute sources

  • Features: Originally suggested generic entity configuration management features; now only locally?:

    • Export/import of config items/entities.
    • Copy/delete (copy as a poor man's versioning).
    • Editing of entities in the GUI (common configuration items, protocol-specific features).
    • Raw config edit.
    • Config check.
    • Apply config.
    • Git config save.
    • Generic post-processor for configs, which could be used for configuration check, deployment, activation, and Git push.
    • Versioning and rollback from Git (Git config restore).
    • Dynamic updates to the configuration without requiring a full joint restart of the GUI, role components, or proxy service (by keeping them apart).

• Metadata Management

  • Federation-level: Interface to add/edit federation-wide metadata.
  • Individual SPs/IdPs: Interface to add/edit metadata for individual SPs/IdPs, with options for manual entry or file import.

• Relation Management

  • Select SP/IdP: Dropdown or search functionality to select an SP/IdP.
  • Activate SP/IdP: Toggle to activate the selected SP/IdP.
  • Attribute Release Policy (SP): Options to configure REFEDs entity categories for SPs.
  • Requested Attributes (IdP): Options to select requested entity categories for IdPs.

• My Metadata

  • Display Name: Field to enter/display the name of the proxy.
  • ?Supported Entity Categories: Checklist or dropdown to select supported categories.
  • Logo: Upload functionality to add a logo.

...

Features for a later version

• Search (of what, where, by what attributes?).
• Proxy wizard.
• Mapping between local and remote admin users , (we could restrict the the MVP to require mutually identical or trusted users).
• Is proxying between SAML and OIDC for a later version beyond the MVP?

• Topology graph.

• Reporting and analytics: statistics, issues, events/logs.
• Audit trail (in addition to basic reports).
• Management of multiple/remote proxy instances.

• Entity lifecycle management: Draft, Test, Production, Support for parked entities/configs, Logically deleted.

• Publicly specified API to access/edit configuration/history of the service and its entities configuration/history.
• Managing (meta)data exchange (at the proxy):
  
  • Management of attribute filtering between IdPs and SPs.
  • Management of mapping of attributes.
  • Attribute transformation rules.
  • Setting of attribute values for entities.
• Possibly contentious:
  • Validation of encryption and signatures of entities and their messages.
  • Enforcement of authentication and authorisation policies (defined locally or by IdPs).
  • Integration with MFA by the proxy.

...