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
Relation management
- Select a SP to make it 'active'
- Attribute Release Policy - Only allow REFEDs entity categories (anoymous, pseudononymous, personalized, R&S)
- Select an IdP to make it 'active'
- Requested attributes - Select which entity category to request.
My Metadata
Setup user facing aspects of proxy
- Displayname,
- Supported entity categories
- Logo
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
Other
- GUI for internal admin of the proxy (for key internal settings apart from managed services' configs)
- Federation/eduGAIN support
- Additional support for federated identity management - what specifically?
- API to access/edit service configuration/history???
- Validation of encryption and signatures of entities and their messages
- Enforcement of authentication and authorization policies - defined locally or by IdPs?
- Integration with MFA by the proxy
- Reporting and analytics - (sounds like an expansion of auditing - correctly chosen audit data and format might make this easier)
- Statistics
- Issues
- Events/logs
- Step back/forward during config changes (Step-by-step wizard for adding a new entity/item)
- Dynamic updates to the configuration without requiring a full restart of the proxy service (GUI is apart from proxy services)
Managing (meta)data exchange
- Management of attribute filtering between IDPs and SPs?
- Management of mapping of attributes
- Attribute transformation rules?
- Setting of attribute values - for which entities?
Key concepts and their (alternative) names
Proxy
Entity
Configuration
IDP/Authorisation Server/OP
SP/RP/client
- do we want to use separate "branches" for OIDC/SAML - specific names or conflate them into our unified terminology?
...