Show pagesourceOld revisionsBacklinksBack to top Recent ChangesSend via e-MailPrintPermalink × This page is not fully translated, yet. Please help completing the translation. (remove this paragraph once the translation is finished) edu-ID – Architecture (back to Overview) See also Working group Technik The following comments are based on the results of the Workshops in November 2019 in Bamberg. See also the Notes and the related Blackboard picture. Key requirements for an edu-ID system Support for central edu-ID use cases Onboarding “Recognition”, uninterrupted use of services Account linking, aggregation of attributes and identities (“affiliations”) Use of local or institution-specific service providers must still be possible Ideally a single IdP as authentication source (i.e. not edu-ID-IdP versus home IdP) edu-ID is issued/generated centrally –> central IdP for onboarding Requirements for home IdPs (are not rendered superfluous by an edu-ID system, but take on a different role in some cases) Must manage edu-ID (the identifier) locally in the IdM …and be able to synchronise attributes with the edu-ID system, ideally via push API (SCIM), attribute query as an emergency/transitional solution Must generally continue to “serve” local SPs (often special configurations) Home IdP as preferred authentication source (in edu-ID scenarios, the edu-ID IdP provides the attributes). Options for a technical solution SWITCH model: A central IdP that is able to emulate the IdPs of the participating home institutions Hybrid model: Home IdPs and edu-ID IdP side by side, edu-ID IdP only for certain SPs / use cases Decentralised model: edu-ID system only provides the identifier and the core attributes provided by the users Favoured solution model Based on hybrid model edu-ID system fulfils several roles: IdP: for homeless users, especially in onboarding scenarios Proxy-SP: home IdP as authentication source –> one user session (SSO) (use case “recognition”, uninterrupted use of services) Attribute and identity aggregator Identifiers derived from edu-ID: (targeted) pairwise-id, occasionally also (unique) subject-id Are generated by the edu-ID system … and could be retrieved and cached by the home IdPs via a data connector (web service). However, this can only be an emergency solution! (difficult for “edu-SPs”) –> SSO better via Proxy-SP (see above) Discovery in “proxy mode” Aim for the best possible user experience Ideally no cascading selection Account linking, aggregation of attributes and identities Push API (like SWITCH) for provisioning user data to the edu-ID system Linking of identities is not automatic, but user-controlled Essential for FIDs and research infrastructures To aggregate IDs reliably (no copy+paste), customised solutions are required (e.g. from ORCID) Registration and initial onboarding Account linking and attribute/ID aggregation edu-ID-System as Proxy Resources & Links Information about SCIM Last modified: 2 months ago Log In