eIDAS-enabled Student Mobility ESMO Project: towards a simpler interoperability Goals, solutions, status and roadmap www.ESMO-project.eu Francisco José Aragó Monzonís, UJI First Online Webinar (Oct 19th 2018) GRANT AGREEMENT UNDER THE CONNECTING EUROPE FACILITY (CEF) - TELECOMMUNICATIONS SECTOR AGREEMENT No INEA/CEF/ICT/A2017/1451951

Sections Introduction: What is ESMO? ESMO Gateway: The Design ESMO Gateway Potential Applications ESMO Network: Leveraging EWP Development Status and Project Roadmap

Introduction: What is ESMO?

Contents Partner Background Objectives What is eIDAS ESMO in CEF and Higher Education: Expected Benefits

ESMO Project CEF Project. 15 months. April 2018 – June 2019 Partners

Participation in STORK and STORK 2.0 projects Partner Background Participation in STORK and STORK 2.0 projects Pilots that settled the technical base for eIDAS. Analysed sustainability of STORK: potentials and pitfalls identified Academic Identity Federations. Feide (Norway) SIR2 (Spain)

Objectives Promote eIDAS adoption through the CEF eID. By minimising adoption costs for SPs. By facilitating the connection of sector specific data sources. Facilitate learning mobility. By enabling eIDAS cross-border electronic authentication. By enabling cross-border exchange of sector specific attributes. By facilitating the deployment of streamlined administrative procedures involving trusted data transfer between institutions. Ease management of trust and data requirements. Promote convergence with EduGAIN, cooperation with other CEF and Erasmus+ projects based on common objectives. Promote collaboration with key higher education stakeholders. by offering multiple protocol endpoints, and protocol and attribute translation for academic SPs/APs. The Gateway will be designed with a wider scope: extensible to allow adding further modular functionality to it. Widespread mobility based on paperless procedures enabled by a widespread cross-border use of eIDAS accepted eIDs, leveraging strong legal , proposing recommendations, road-mapping and collaboration measures foundation of eIDAS. Phased scalable interconnection of academic data sources and services (incl. future mutual eIDAS & eduGAIN inter-federation):

What is eIDAS? European regulation on eID and Signature Based on cooperation and reciprocity between states Establishes Mutual recognition of eID schemes Levels high and substantial: mandatory Level low: optional Member states have sovereignty over: Which schemes are notified Organisation of the federation at national level. Mandatory for public services Which accept at least substantial or high authentication mechanisms

eIDAS Nodes Status Slide by: EC DG CONNECT

eIDAS eID Notification Status Croatia High PEER REVIEWED 11 Jul 2018  Germany NOTIFIED 26 Sep 2017  Estonia Luxembourg United Kingdom PRE-NOTIFIED 28 Aug 2018  Portugal 30 May 2018  Belgium 28 May 2018  Spain Italy Low -High 10 Sep 2018 https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+pre-notified+and+notified+eID+schemes+under+eIDAS

eIDAS enforcement Supporting infrastructure for compliance. Based on interoperability specification (derived from STORK). Deployed by each member state Neutral Open Source Based on the CEF reference implementation Mesh of national nodes Nodes proxy their national SP and IdP. CEF is a funding programme (2014-2020) to support the deployment of pan-European communication networks. Digital Single Market strategy Node deployment funding Service integration funding Interest on student mobility services WP 2014 provided for the building of the nodes (connection points) within Member States which are essential to the interoperability framework. Version 1.1 of the technical specifications for the nodes was recently published. WP 2015 provided for the connection of Member State public services to the node, thereby enabling cross border transactions compliant with the eIDAS Regulation. WP 2016 shifted the focus for connection to the node mainly to private sector entities with potentially high volume of cross border transactions, such as financial institutions. WP 2017 further supported the building of nodes for those Member States who have not yet done so, the integration of eID in existing e-service/system/online platform to enable private and public sector entities (including local administrations) to accept eIDs and eIDAS authentication to facilitate the mobility of students in the European Union.

eIDAS Interoperability Architecture Slide by: EC DG CONNECT

eIDAS Strengths and Opportunities Backed by Member States Top-down adoption Stable specifications High trust standards for identities Enable high-trust services Expected wide support among public sector bodies Can be extended to support domain specific cases

eIDAS Adoption Barriers Recent specification Focus on government sector Limited attribute set can be transported Relatively restricted metadata flow. Restricted trust model (proxy model). Restricted access model for SPs Not yet defined for private sector. High IdP acceptance standards. Restricted offer of services requiring such standards. Governance by Member States Less flexibility for SPs Less usability of credentials

ESMO in CEF and Higher Education: Expected Benefits Maximizing impact by enlarging CEF eID adoption by attracting: Students user base. Academic attribute providers. Online services. Enable high trust student mobility services requiring authorisation based on the academic profile. Decrease administrative burden. Facilitate compliance: eIDAS, GDPR, Digital Education Action Plan… Enable the transferring of attributes, useful to model sector-specific needs, in a more flexible fashion than eIDAS does. Bring together eduGAIN and eIDAS. Extend results to other sectors. Examples of potential services Enrolment with trusted grades recognition. Job Placement and demand Job qualification assurance Services targeted for certain student population groups without the need for prior registration (discounts, surveys...).

ESMO Gateway: The Design

Contents Design principles Gateway Features Functional Design Technical Design Communication Security Communication Protocols

Scalability Concentrate development effort Design principles Concentrate development effort Protocol and attribute set translation Abstraction (transparent proxy) Flexibility (multiple topologies) Modularity and extendability Easy to add new functional modules Tune behaviour via configuration. Scalability

Use common development technologies Reuse existing solutions Design approach Modular design Microservices Allows for more independent module development. Allows multiple technologies to be used Use common development technologies Reuse existing solutions

Will accept requests for eIDAS authentication in: Gateway Features Will accept requests for eIDAS authentication in: SAML2Int, SAML2eIDAS, OIDC Requests can include additional academic attributes to be retrieved from HEI APs. Will act as a proxy for the relying parties, managing the complexity and the trust of the data collection. Will act as a proxy for the data sources, acting as a single point of entry and trust manager for the requests to be handled by the data sources. ESMO GW provides trust and governance of SPs and APs connecting to eIDAS authentication and sector specific attributes exchange services.

Functional Design

Functional Modules SP Connector: Inbound request from SPs IdP Connector: Outboud auth requests to an IdP AP Connector: Outbound attribute requests to an AP GW Connector: Inbound attribute requests from another GW (contain trusted data) Session Manager: Store session data and issue security tokens ACM: Cental module. Top-level business logic. Relays on the other functional modules. Discovery module: Allows discovery of Aps/IdPs, with UI or transparent.

Functional Modules Attribute processing module: Transform the attribute set being processed Trust Connector: Publish trust info or negotiate trust with other entities. Publish internally trusted entity info through the Metadata Interface Configuration Manager: Handle local configuration or trust info Metadata interface. Publish internally trusted entity info through the Metadata Interface. Data Requirements: Entity Metadata Object: Represents generically the required information from the Aps/SPs/IdPs/GWs Attribute List Object: Represents generically requests and responses

Technical Design

Technical Design: Micro-Services Session Manager micro-service: Keep session data, issue and validate tokens. ACM micro-service: Main business logic. Will also implement local configuration, discovery and attribute transformation modules. EWP micro-service: Will handle the trust interaction with EWP and also wil feed the ACM discovery service through the metadata interface. SAML micro-service: All SAML2 protocol related modules (SP, AP and IdP).

Technical Design: Micro-Services OIDC micro-service: All SAML2 protocol related modules (SP, AP and IdP). GW2GW micro-service: The custom protocol for Gateways, the client and the server parts (through a GW and an AP modules). NO Specific micro-service: Will handle the Dataporten OAuth2 based specific AP and SP interaction. GR Specific micro-service: Will handle part of the Greek specific AP interaction (the other will be SAML), OAuth2 based .

ACM Activity

Communication Security Two levels: Internal: between micro-services inside the GW External: between the GW and entities (SPs,Aps, IdPs, GWs) External: Accept only signed requests. Accept only signed and encrypted responses. Trust on entities established trough deferred channel or through a trusted third party. Lists of SPs/GWs allowed to request Lists of Aps/IdPs/GWs whose responses will be accepted

Communication Security Internal: Micro-services (ms) potentially accessible by unauthorised requestors. Normal application flow can be bypassed maliciously. Personal data theft concerns. 2 kind of interfaces for microservices: Bach-channel: Direct ms to ms communication. No UI. Front-channel: Allows UI. Redirection through user-agent communication.

Communication Security Internal: Back-channel security: SSL to authenticate the server and secure the channel HTTP-Signature to authenticate the client (and requestor) Front-channel security: Signed tokens to authenticate the requestor (not the client). Sensible data on front-channel interactions to be passed over the Session Manager for additional security. All connections to the SM are back-channel.

Communication protocols Micro-service communication: With the Session Manager: all back-channel connections (no UI) UI-supporting microservices: Pass a signed JWT token along the redirection. The token is generated and validated by the Session Manager The caller ms will request it to the SM through back-channel. The invoked ms will send it to the SM for validation through back- channel. Will inlude validity, caller ID and icalled ID for ms access control.

Communication protocols Accepted from SPs: SAML2Int, SAML2eIDAS, OIDC, OAUTH To query IdPs or APs: Gateway to Gateway: Front-channel. Custom approach: HTTP-POST (through SSL) redirection (most common SAML2 binding) JWT token passed (instead of SAML2 XML token) Tokens will be signed (JWS) and encrypted (JWE) to additionally secure the data and to authenticate the requestor (not the client). JWE with the actual JSON data as the payload of a JWS.

ESMO Gateway Potential Applications

Basic Use Cases Proxy Network Use Case Interoperability challenges Contents Basic Use Cases Proxy Network Use Case Interoperability challenges

Proxy for an AP at the HEI Basic Use Cases Proxy for a SP at the HEI Deployed locally or to provide protocol translation, As an abstraction layer. Multiple SPs on the HEI could connect. Proxy for an AP at the HEI Additional security/trust layer. Multiple data sources on the HEI could rely on it.

Gateways can be interconnected Proxy Network Use Case Gateways can be interconnected Forming meshes or hierarchies Mesh of proxies = eIDAS ESMO can deploy an eIDAS supporting network Enhancing functionality of eIDAS for sector specific needs (multi-origin cross-border DSA collection). Can be seen as a wrapper. No data persistence, user-driven  minimise legal concerns for this approach.

ESMO Proxy Network Topology On the ESMO deployment topology, each GW will correspond to a MS

Interoperability challenges Re-authentication On the APs, to authorise access to data.  More complex user experience eIDAS authentication might be used, but: AP access protocol might not support the passing of auth data Identities not linked

Interoperability challenges IdP-AP Identity Linking Targeted identifiers at each requesting entity, different local identifiers. Mitigations: Re-authentication + AP sending personal attributes to compare (transliteration and representation problems) Identifier linking service (user-driven, to avoid legal concerns)

Interoperability challenges Attribute set supported: Based on EduPerson, SCHAC to promote the de-facto standards in the sector. Translation between attribute profiles, based Study Programme

Supported Attribute Profile eduPersonUniqueId eduOrgLegalName eduPersonAffiliation eduOrgL eduPersonPrimaryAffiliation o mail eduOrgHomePageURI schacExpiryDate eduPersonprincipalName mobile eduPersonPrincipalNamePrior eduOrgPostalAddress displayName eduOrgCn givenName schacHomeOrganization sn eduPersonOrgUnitDN schacDateOfBirth

Study Program urn:mace:europa.eu:edu:<INSTITUTION>:program:<YEAR>:<PROGRAM_CATEGORY>? :<PROGRAM_ID>:<PROGRAM_DISPLAY_NAME>:<AFFILIATION>   INSTITUTION: institution's domain name YEAR: year the program is officially created  PROGRAM_CATEGORY: could be used as a field to group similar programs in different institutions or use it internally to define knowledge areas ---needs better semantic definition. PROGRAM_ID: automated identifier of the program PROGRAM_DISPLAY_NAME: urlencoded display name of the program, in the institution official language and naming. AFFILIATION: using the eduperson affiliation value set, define the relationship to the program (staff, student, etc.) Example: urn:mace:europa.eu:edu:uji.es:program:2001:science:II: Enginyeria%20Inform%C3%A0tica:student

ESMO Network: Leveraging EWP

The Importance of Convergence Potentials of EWP ESMO Network and EWP Contents The Importance of Convergence Potentials of EWP ESMO Network and EWP

The Importance of Convergence Avoid duplication of efforts + coordinated workforce Single point of entry Multiple ways to achieve (most convenient) Standardisation & usage of standards Multiple views discussing turn into a more solid design

EWP solves a complex cross-border service use case. Potentials of EWP EWP solves a complex cross-border service use case. Network of HEIs, Erasmus lifecycle digitalisation. Potentially to be adopted by all European HEIs Extendable technical design Builds a network of Trust Network of trust can be leveraged for other uses

ESMO GW will build their trust over EWP ESMO Network and EWP ESMO GW will build their trust over EWP EWP registry Will rely on the other GWs present on the registry ESMO GW will offer additional apis for EWP Will publish the access endpoints on the registry, so they can be used by any HEI eIDAS authentication User-driven access to academic attributes

ESMO Network Architecture The user accesses a Service Provider. The SP requests authentication to eIDAS and some other academic attributes by delegating to the GW. The originating GW relays the authentication to eIDAS. After receiving the authentication assertion, will ask the user which attribute providers to query to get the academic attributes (and the consent to pass the authentication attributes). If the Attribute Provider is connected to another Gateway, the Originating Gateway will relay the request to that GW (including the authentication attributes). If the Attribute Provider is connected to the same Gateway, it will relay the request to the Attribute Provider (including the authentication attributes). The trust in other Gateways is derived from their inclusion on the EWP registry. When all the responses with the attributes are in the Originating GW, it will issue a composite response to the SP. Originating GW and Destination GW might be on different countries Also, different sector authorities in a MS could deploy their own GW. CEF eID credential used in Originating GW might be from a country different that the Originating GW country.

Example ESMO Use Case: Gateway Detail EWP Register Trust relationship. ConfigMngr ms HEI A SP HEI B HEI X AP eIDAS SP OIDC ms eIDAS SAML ms ACM ms SP SAML ms AP OAuth ms Session Mngr ms AP JWT ms ESMO GW UA ESMO Gateway

Example Advanced ESMO Use Case: Overall View authenticate country selector: IT eIDAS attributes eIDAS Authentication Request Attribute aggregation & consent match eIDAS Id & atributes or re-authenticate DSA Request (ES, HEI X) User tries to access e-service and is redirected to authenticate on eIDAS MDS DSA HEI X Academic Attributes Redirected to ESMO GW DSA Request (GR, HEI Y) HEI Y Academic Attributes Final consent on AVPs to be returned to the SP match eIDAS Id & atributes or re-authenticate

Development Status and Project Roadmap

Current Status of the development Development Timeline Future Plans and Sustainability

Current Status of the development Development work assigned and started Shared development of the micro-services Analysis of the HEI services and data sources to be connected finalised Customisation ongoing

Pre-production GW network: February 2019 Development Timeline Pre-production GW network: February 2019 Production GW network: April 2019 3 Nodes (Spain, Greece, Norway)

Future Plans and Sustainability Maintenance of the project as open source code By the partners at first Form a community at mid-long term Governance of the deployed Gateways Seek support by reference institutions in the sector (NRENs, ministries, education boards or governance bodies) Promote adoption by other countries

Project Media and Participation Project Web Page: http://www.esmo-project.eu/ News Documentation Source code downloads Materials (Technical design: D2.1): http://www.esmo-project.eu/content/publications Twitter: https://twitter.com/CefEsmo News and updates Academic Monitoring Group If you are interested, contact: farago@uji.es

Thank you for your attention Francisco José Aragó Monzonís farago@uji.es GRANT AGREEMENT UNDER THE CONNECTING EUROPE FACILITY (CEF) - TELECOMMUNICATIONS SECTOR AGREEMENT No INEA/CEF/ICT/A2017/1451951 www.ESMO-project.eu