You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Current »

Use cases

Initial setup after installation

The instance may participate in one or more federations. "Federation" is a generic term here, encompassing SAML federations, a collection of OIDC parties, or an intra-organisation set of entities (internal federation). The instance will have an identity as either a service provider (SAML SP or OIDC RP), an identity provider (SAML IdP or OIDC OP), or both. These roles will define the deployment’s identity.

  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


Adding remote entity metadata

Context: The user can add metadata for the entities this deployment should know and trust.

  1. On the metadata management screen, the user presses "Add Remote 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 a file or URL.
    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.

Specific features:

  • Step back/forward during config changes (step-by-step wizard for adding a new entity/item)?
  • Should metadata feed into SSP and SaToSa configurations, or should we limit the MVP to one platform?
  • Add/remove entity metadata to participated federation(s)?
  • Could remote entities be offered based on federation metadata?

Adding metadata source

Context: You can add an MDQ source and trust everything retrieved from it. In a future, more advanced version, you may also be able to add an OIDFed intermediate authority.

TBD

Deactivate/activate remote entity

  1. On the metadata screen, entities already added to the instance should be able to be deactivated and reactivated (via a button or checkbox).

Features: What about notifying the changed status to other known related entities?

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?

Edit data sources and data release (not MVP)

Context: This applies only if a SAML IdP or OIDC OP role is enabled.

Note: For the MVP, custom attribute release per remote entity is not implemented. Instead, there is a generic setup that may still be conditional on remote entity categories (e.g., CoCo gets more {attributes?}).

  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.

 Common actions → visual components

  1. Navigation

    1. Top Navigation Bar: Links to main sections like Dashboard, Metadata Management, Relation Management, and My Metadata.
    2. Sidebar Navigation: For quick access to subsections within the main areas.
  2. Forms and Input Fields

    1. Text Input Fields: For entering metadata, display names, and other textual information.
    2. Dropdown Menus: For selecting options such as entity categories, SPs, and IdPs.
    3. Checkboxes and Radio Buttons: For selecting multiple or single options, such as supported entity categories and requested attributes.
    4. File Upload Fields: For importing metadata files or uploading logos.
    5. Toggle Switches: For activating or deactivating SPs/IdPs.
  3. Buttons and Actions

    1. Primary Action Buttons: For saving, adding, or submitting forms.
    2. Secondary Action Buttons: For cancelling, editing, or deleting actions.
    3. Icon Buttons: For quick actions like editing or deleting items in a list.
  4. Tables and Lists

    1. Data Tables: For displaying lists of SPs/IdPs, including columns for relevant metadata and actions.
    2. Paginated Lists: For managing large datasets with navigation controls.
    3. Expandable Rows: For viewing detailed information about a specific SP/IdP within a table.
  5. Modals and Dialogs

    1. Confirmation Dialogs: For confirming actions like deletions or important changes.
    2. Form Modals: For adding or editing metadata in a focused environment.
  6. Search and Filter

    1. Search Bars: For finding specific SPs/IdPs or metadata entries.
    2. Filter Options: For narrowing down lists based on criteria like entity categories or active status.
  7. Feedback and Notifications

    1. Toast Notifications: For temporary messages about actions (e.g., "Metadata saved successfully").
    2. Error Messages: Inline or modal messages for form validation errors or system issues.
    3. Success Messages: Inline or modal messages confirming successful actions.
  8. Dashboard Widgets

    1. Summary Cards: For displaying key metrics and statuses (e.g., total SPs, active IdPs).
    2. Activity Feeds: For showing recent actions and changes.
  9. Visual Indicators

    1. Status Badges: For indicating the status of SPs/IdPs (e.g., active, inactive).
    2. Progress Bars: For showing the progress of actions like file uploads or metadata synchronisation.
  10. User Profile and Settings

    1. Profile Dropdown: For user account management, logout, and settings.
    2. Settings Page: For configuring user preferences and system settings.

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 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.

Wireframes


  • No labels