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