1. eIDAS-enabled Student Mobility
ESMO Project: towards a simpler interoperability
Goals, solutions, status and roadmap
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/

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

3. Introduction: What is ESMO?

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

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

6. 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)

7. 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):

8. 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

9. eIDAS Nodes Status
Slide by: EC DG CONNECT

10. 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

11. 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 ( ) 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.

12. eIDAS Interoperability Architecture
Slide by: EC DG CONNECT

13. 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

14. 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

15. 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...).

16. ESMO Gateway: The Design

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

18. 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

19. 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

20. 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.

21. Functional Design

22. 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.

23. 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

24. Technical Design

25. 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).

26. 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 .

27. ACM Activity

28. 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

29. 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.

30. 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.

31. 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.

32. 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.

33. ESMO Gateway Potential Applications

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

35. 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.

36. 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.

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

38. 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

39. 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)

40. 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

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

42. 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

43. ESMO Network: Leveraging EWP

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

45. 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

46. 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

47. 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

48. 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.

49. 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

50. 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

51. Development Status and Project Roadmap

52. Current Status of the development
Development Timeline
Future Plans and Sustainability

53. 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

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

55. 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

56. Project Media and Participation
Project Web Page:
News
Documentation
Source code downloads
Materials (Technical design: D2.1):
Twitter:
News and updates
Academic Monitoring Group
If you are interested, contact:

57. Thank you for your attention Francisco José Aragó Monzonís
GRANT AGREEMENT UNDER THE CONNECTING EUROPE FACILITY (CEF) - TELECOMMUNICATIONS SECTOR
AGREEMENT No INEA/CEF/ICT/A2017/