1. eIDAS-enabled Student Mobility
ESMO Gateway: a Technical Approach
Features and Technical Achievements
Francisco José Aragó Monzonís, UJI
ESMO Workshop
(Trondheim, June 3rd 2019)
GRANT AGREEMENT UNDER THE CONNECTING EUROPE FACILITY (CEF) - TELECOMMUNICATIONS SECTOR
AGREEMENT No INEA/CEF/ICT/A2017/

2. Contents Objectives Design principles Gateway Features
Functional Design
Technical Design
Communication Security
Communication Protocols

3. Develop a federation proxy tool
Objectives
Develop a federation proxy tool
Support exchange of sector specific attributes.
Interoperable with eIDAS
Interoperable with EduGAIN
Allows delegation of trust
Allows delegation of entity management
Provide attribute aggregation capacity
With Multi-protocol support both for SPs, IDPs and APs
With protocol translation capabilities
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):
Build general-purpose internal transfer objects covering all targeted protocols
Cover features mismatch between protocols with additional metadata

4. Maximise reusable parts Abstraction
Design principles
Maximise reusable parts
Abstraction
Flexibility (allow multiple topologies)
Modularity and extendability
Easy to add new functional modules
Alter behaviour via configuration as much as possible.
Scalability
Adapt to demand and offer high availability

5. Microservices architecture
Design approach
Modular design
Microservices architecture
Allows for more independent module development.
Allows multiple technologies to be used
Facilitates hot-plugging of new modules or replicated instances
Use common development technologies
Reuse existing solutions
Concentrate state and configuration on central elements

6. Gateway Features Accepts requests for eIDAS authentication in:
SAML2Int, SAML2eIDAS, OIDC
Requests can include additional academic attributes to be retrieved from HEI APs.
EduPerson, SCHAC, eIDAS
For protocols not supporting attributes on request, they can be specified in metadata
Iterative collection from an unbound number of APs on a single flow
Proxy for the relying parties, managing the complexity and the trust of the data collection.
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.

7. Easy deployment (Docker composer)
Gateway Features
Does not store user information, user centred application flow. Which facilitates GDPR compliance.
Hot-plugging of new modules or additional instances to cover demand or high availability
Easy deployment (Docker composer)
Deploy just the functional modules you need
Simple, centralised configuration
State is centred in a single microservice
Integration with EduGAIN (through RedIRIS)
ESMO GW provides trust and governance of SPs and APs connecting to eIDAS authentication and sector specific attributes exchange services.

8. Functional Design: final

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

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

11. Technical Design: final

12. Technical Design: Core Micro-Services
Session Manager micro-service: Keep session data, issue and validate tokens.
Config Manager micro-service: Keeps centralised configuration, both internal and the external entities metadata. Has an internal module to interact with the EWP registry.
ACM micro-service: Main business logic. Will also implement local configuration, discovery and attribute transformation modules.

13. Technical Design: Protocol Specific Micro-Services
SAML micro-service: All SAML2 protocol related modules (SP, AP and IdP), for SAML2Int and SAML2-eIDAS, based on Simple SAML PHP.
SAML IDP micro-service: based on keycloack application.
OIDC/OAUTH2 SP, IdP and AP micro-services: Handlers of the OIDC requests for the three cases, separated implementations.
GW2GW micro-service: The custom protocol for Gateways, the client and the server parts (through a GW and an AP modules).

14. ACM Logic

15. MultiUI

16. Supported Attribute Profile
Attribute set supported:
Based on EduPerson, SCHAC to promote the de-facto standards in the sector.
eduPersonUniqueId
eduOrgLegalName
eduPersonAffiliation
eduOrgL
eduPersonPrimaryAffiliation o
mail
eduOrgHomePageURI
schacExpiryDate
eduPersonprincipalName
mobile
eduPersonPrincipalNamePrior
eduOrgPostalAddress
displayName
eduOrgCn
givenName
schacHomeOrganization sn
eduPersonOrgUnitDN
schacDateOfBirth

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

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

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

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

21. Communication protocols
Accepted from SPs:
SAML2Int, SAML2eIDAS, OIDC
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.

22. Developed components to support the requirements on the agreement.
Conclusions
Developed components to support the requirements on the agreement.
Achieved all technical design goals
Design is more ambitious than originally planned
The choice of design principles proved to be the fittest to reach beyond the initial goals
Big development overhead that was covered with additional resource allocation
Provides some new features that will be more appealing for adopters
Hot-plug scalability
Flexible and less effort for high-availability deployment
Simpler and platform independent deployment

23. Conclusions
ESMO Gateway can be a flexible and competitive tool for many scenarios
This will increase as it gets improvements through modules deployment and experience gathered through usage
Architecture and communications security model can be reused and improved for other situation and or initiatives (SEAL)

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