MVP 0.1
Metadata Management
- Add/Remove metadata (endpoint) for the 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 (anonymous, pseudonymous, 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
Features for a 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 locally-managed 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 configuration deployment and activation and Git push
- Management of individual IDPs/Authorisation Servers/OPs and SPs/RPs/clients within the SP proxy
- Config checks (could also be one of the 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 authorisation 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
These suggestions are for now mostly SAML flavoured to suit the target users:
- Identity provider - IdP or OP (OpenID Provider), while Authorisation Server is a more specific role
- Service provider - SP or RP/client ("client" is rather an OAuth2 term and is too overloaded)
- Entity - Identity provider or service provider
- Identity proxy - For now this, or "SP proxy", not "proxy" nor "client proxy". Consider "Identity Broker" to make this more general?
- Configuration - settings (in a text file, optionally in a GUI) for an identity provider, service provider or SP proxy
Identity Federation - technical and organisational arrangement connecting multiple identity providers (IdPs) and service providers (SPs) to allow users to authenticate and access resources across different domains with a single set of credentials.
- ...
Consider whether to use separate terminological "branches" for OIDC/SAML - specific names or conflate them into a unified terminology?