1 / 24

ESMO Gateway: a Technical Approach

eIDAS -enabled Student Mobility. ESMO Gateway: a Technical Approach. Features and Technical Achievements. www.ESMO-project.eu. Francisco José Aragó Monzonís , UJI. ESMO Workshop (Trondheim, June 3 rd 2019).

yank
Download Presentation

ESMO Gateway: a Technical Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. eIDAS-enabled Student Mobility ESMO Gateway: a Technical Approach Features and Technical Achievements www.ESMO-project.eu 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/1451951

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

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

  4. 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. 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 authenticationin: • 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.

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

  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 • eduPersonUniqueId • eduPersonAffiliation • eduPersonPrimaryAffiliation • mail • schacExpiryDate • mobile • eduOrgPostalAddress • eduOrgCn • schacHomeOrganization • eduPersonOrgUnitDN • eduOrgLegalName • eduOrgL • o • eduOrgHomePageURI • eduPersonprincipalName • eduPersonPrincipalNamePrior • displayName • givenName • sn • schacDateOfBirth • Attribute set supported: • Based on EduPerson, SCHAC to promote the de-facto standards in the sector.

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

  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. 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 farago@uji.es GRANT AGREEMENT UNDER THE CONNECTING EUROPE FACILITY (CEF) - TELECOMMUNICATIONS SECTOR AGREEMENT No INEA/CEF/ICT/A2017/1451951 www.ESMO-project.eu

More Related