Page History

...

1. After deployment, the "My Metadata" screen is initially empty.
2. Using an "Add Role" button (we might rename it if a better suggestion arises), the user can select one of the following: SAML IdP, OIDC OP, SAML SP, OIDC RP.
3. Regardless of the selected role, the user can set up a Display Name and a Logo.
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

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:

...

Adding remote entity metadata

...

• 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 feed into SSP and SaToSa configurations, or should we limit the MVP to one platform, 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), you can act as a proxy. In this case, a configuration option that was previously unavailable ("grey") becomes available as 'Proxy Configuration.'
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.

...

• Search (of what, where, by what attributes?).
• Proxy wizard.
• Mapping between local and remote admin users (we could restrict 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.
• Managing (meta)data exchange (at the proxy):
  
  • Management of attribute filtering between IdPs and SPs.
  • Management of mapping of attributes.
  • Attribute transformation rules.
  • Setting 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.

...