Applying eduGAIN to network operations The perfSONAR case

1. Applying eduGAIN to network operationsThe perfSONAR case Diego R. Lopez (RedIRIS) Maurizio Molina (DANTE)

2. perfSONAR • perfSONAR is a highly distributed and dynamic network measurement infrastructure User Interface Layer User interface 1 User interface 2 Service Layer Domain A - services Domain B - services Domain C - services Measurement Point Layer Domain A Domain B Domain C Metric type 1 Measurement Point Metric type 2 Measurement Point Metric type 3 Measurement Point

3. perfSONAR and AAI • perfSONAR is built upon many interdependent components • Independently deployed • Subject to local rules for access and usage • Federating solutions for AuthN/AuthZ seem the only acceptable ones • Already existing federations in many domains • It is necessary to federate federations • eduGAIN is the GÉANT2 solution for this

4. eduGAIN: AAI for GÉANT2 • Started from • Scattered AAI implementations in the EU and abroad • The basic idea of federating them, preserving hard-won achievements • Based on the idea of confederation • A loosely-coupled set of cooperating identity federations • Identity management and AuthN/AuthZ must be properly handled by the participating federations • Dynamically established trust links

5. The perfSONAR Model for AuthN/AuthZ • At each perfSONAR participating domain there exists an instance of the Authentication Service (AS) • Acting as a proxy between the AuthN/AuthZ and the perfSONAR infrastructures • There is a direct trust relationship between resources and the AS in their domain • AS relieves resources from deployment and administrative overhead related to AuthN/AuthZ operations • AS takes resource access (AuthZ) decisions on the basis of common domain policies • Though resources or resource protectors can ultimately deny access because of resource availability

6. The eduGAIN Model • Use a set of interconnection points (Bridging Element, BE) at each federation • Announce BE metadata through the FPP (Federation Peering Point) • Distribute these metadata through the Metadata Service (MDS) • Metadata is used by the requesting BE to establish the trust links • BEs exchange data using the eduGAIN SAML-based profiles

7. Connect. Communicate. Collaborate The eduGAIN Model Metadata Query MDS Metadata Publish Metadata Publish R-FPP H-FPP R-BE H-BE AA Interaction AA Interaction AA Interaction Resource(s) Id Repository(ies)

8. Connect. Communicate. Collaborate Putting It All Together

9. eduGAIN Operations • Defined in abstract terms, following the SOA paradigm • Metadata Service (MDS) • Authentication Service (AuthN) • Attribute Exchange Service (Attr) • Authorisation Service (AuthZ) • Formally defined parameters for each operation • Bindings defined for SAML 1.1 and part of SAML 2.0 • Plans for evolving these bindings as required

10. eduGAIN Operation Binding • Current version is based on SAML 1.1 • Profiling the standard to fit abstract parameters • Component identifiers play their role again • A SAML 2.0 implementation will be available along the lifetime of the project • The abstract service specification protects components and applications from these changes • Authentication assertions and attribute exchange mechanisms are designed to be Shibboleth 1.x compatible • And Shibboleth 2.0 in the future

11. eduGAIN Trust Fabric • Based on a PKI • Validation procedures include • Normal certificate validation • Trust path evaluation, signatures, revocation,… • Peer identification • Certificates hold the component identifier • It must match the appropriate metadata • Applicable to • TLS connections between components • Two-way validation is mandatory • Verification of signed XML assertions

12. Component Identifiers • eduGAIN operations strongly depend on having unique, structured and well-defined component identifiers • Based on URNs delegated by the eduGAIN registry to the participating federation • Identifiers establish the kind of component they apply to by means of normalized prefixes • Identifiers follow the hierarchy of the trust establishing process • Including the identifiers of the federation (and BE) the component is using to connect to eduGAIN

13. The eduGAIN API • Common libraries for all eduGAIN components • Implementation of the eduGAIN service definition, metadata access and validation procedures • The interface is based on specific classes modeling the abstract definition: AuthNReq, AuthNResp,… • Is a general abstraction layer for AuthN/AuthZ operations • Applicable to perfSONAR clients and AS for interactions in the eduGAIN trust zone • And to resources and other components for interactions in the internal trust zone

14. Profiles • Define the precise exchange of messages and the processing rules for these messages in particular use cases • Defined in a joint perfSONAR-eduGAIN specification document • Two profiles defined so far • Automated client (no human interaction) • Client on behalf of a user (derived from Web SSO) • The eduGAIN API provides specific access to elements implementing the profile logic • Simpler usage • Easier interoperability

15. Connect. Communicate. Collaborate A Layered Model eduGAIN API Profile logic Basic eduGAIN services: validation, metadata, service adaptation,… SAML library  OpenSAML SOAP/TLS/XMLSig libraries  Shibboleth components whenever possible

16. Connect. Communicate. Collaborate Profiles: Automated Client Certificate installed in the client SH: Client identifier plus (optional) attributes Optional steps to verify properties of SH and/or retrieve additional attributes

17. Connect. Communicate. Collaborate Profiles: Client on Behalf of a User The identity of the user must be established by the client through direct interaction with the user’s IdP. Work is in progress to provide a simpler Alternative sequence

18. The GÉANT2 IdP (GIdP) • eduGAIN assumes that “NREN level” AAIs are in place and register the identity and attributes of users at their “Homes” • This may not be always the case • In the short term • For all early adopters of GÉANT2 services (including perfSONAR) • GIdP fills a temporal gap • For those potential users of GÉANT2 services that are within NRENs / end institutions without an AAI in place, or not yet connected to eduGAIN • GIdP allows defining an initial trust and resource access model for GÉANT2 services that can be refined/adjusted in the future.

19. Connect. Communicate. Collaborate IdP AuthN Attributes GIdP: The “Home of Last Resort” for eduGAIN Users GIdP User accesses authenticates GIdP H-BE R-BE R-AS pSR eduGAIN Resource’s Domain (Remote) GIdP Domain (Home)

20. Where We Are • Implementing the eduGAIN APIs • Defining the GIdP service • Polishing profiles • First pilot to be run around 4th quarter of this year • Establishing links with other potential user communities • Inside GÉANT2: JRA3 (bandwidth-on-demand) and JRA2 (security) • And beyond: the LOBSTER project • Starting an initiative to connect network access (eduroam) and AAI (eduGAIN): DAMe

21. Connect. Communicate. Collaborate Time for Your Questions (and Your Applause)