Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

MVP 0.1

Assumptions:

  • We assume the number of connected entities is less than X (<50)

Open Question:

  • Do we have 1 entity endpoint (so only the whole proxy), or do we publish separate endpoints for each and every entity we have connected?

Proposed features

To be prioritised for an MVP

  • Translating between SAML and OIDC

Audit trail

"Proxy Wizard"

  • Ability to configure entities preloaded into the proxy based on entity federation metadata

Proxy Administration

  • Local accounts and roles? Or a single admin user?

Metadata Management

  • Add/Remove metadata (endpoint) for entire federation
    • SSP: feeds into the configuration of Metarefresh
    • SaToSa: ?
  • Add/Remove metadata (endpoint) for individual SPs/IdPs

...

  • Displayname,
  • Supported entity categories
  • Logo


Features for later version

Assumptions:

  • We assume the number of connected entities is less than X (<50)

Open Question:

  • Do we have 1 entity endpoint (so only the whole proxy), or do we publish separate endpoints for each and every entity we have connected?

Proposed features

To be prioritised for an MVP

  • Translating between SAML and OIDC

Audit trail

"Proxy Wizard"

  • Ability to configure entities preloaded into the proxy based on entity federation metadata

Proxy Administration

  • Local accounts and roles? Or a single admin user?


Entity management

  • Configuration of SAML IdP
    • Select entity which exist based on federation metadata
  • Configuration of SAML SP
  • Configuration of OIDC OP
  • Configuration of OIDC RP
  • Generic entity configuration management
    • Export/import of config items/entities
    • Copy/delete (copy as poor man's versioning, should it also work on groups of items)
    • Editing of entities in the GUI (common configuration items, protocol specific features)
    • Raw config edit
      • Is the GUI a facade that allows only basic configuration for beginners? If so, how do we represent more complicated valid configs that were created manually?
      • What happens if the config is broken by the user's manual changes? Display an error in the GUI and allow rollback to the previous version?
    • Apply config
    • Git config save
    • Generic post processor for configs (could be used to implement (config and Git push)
  • Management of individual IDPs/Authorisation Servers/OPs and SPs/RPs/clients within the proxy (naming - "client" is more an Oauth2 term and too overloaded)
  • Config checks (could also be one of post-processors)
  • Versioning
  • Rollback from Git (Git config restore)
  • Topology graph
  • Management of multiple proxy instances
  • Management of proxy (related) data for individual entities
  • Entity lifecycle (expressed as states in the GUI? - what is the consequence of being in a certain state?)
    • Draft
    • Test
    • Production
    • Support for parked entities/configs
    • Logically deleted

...