ESMO Project: towards a simpler interoperability

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

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

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 Slideby: EC DG CONNECT

10. eIDAS eID Notification Status

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 (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

12. eIDAS Interoperability Architecture Slideby: 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

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.

16. ESMO Gateway: The Design

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

18. 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. Design approach • Modular design • Microservices • Allows for more independent module development. • Allows multiple technologies to be used • Use commondevelopmenttechnologies • Reuseexistingsolutions

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

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: • SSL to authenticate the server and secure the channel • 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: • SAML2Int, SAML2eIDAS, OIDC, OAUTH • 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. Contents Basic Use Cases Proxy Network Use Case Interoperability challenges

35. 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 • Deployed locally or to provide protocol translation, • Additional security/trust layer. • Multiple data sources on the HEI could rely on it.

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

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 • eduPersonAffiliation • eduPersonPrimaryAffiliation • mail • schacExpiryDate • mobile • eduOrgPostalAddress • eduOrgCn • schacHomeOrganization • eduPersonOrgUnitDN • eduOrgLegalName • eduOrgL • o • eduOrgHomePageURI • eduPersonprincipalName • eduPersonPrincipalNamePrior • displayName • givenName • sn • 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. 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. 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 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

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

50. ExampleAdvanced ESMO Use Case: Overall View authenticate country selector: IT eIDASattributes eIDAS Authentication Request Attributeaggregation & 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 AcademicAttributes Final consent onAVPsto be returnedtothe SP match eIDAS Id & atributes or re-authenticate Redirected to ESMO GW DSA Request (GR, HEI Y) HEI Y AcademicAttributes