Connect Communicate Collaborate Applying edu GAIN to network

Connect. Communicate. Collaborate Applying edu. GAIN to network operations The perf. SONAR case Diego R. Lopez (Red. IRIS) Maurizio Molina (DANTE)

perf. SONAR Connect. Communicate. Collaborate • perf. SONAR 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 Metric type 1 Measurement Point Domain B Metric type 2 Measurement Point Domain C Metric type 3 Measurement Point

perf. SONAR and AAI Connect. Communicate. Collaborate • perf. SONAR is built upon many interdependent components – Independently deployed – Subject to local rules for access and usage • Federating solutions for Auth. N/Auth. Z seem the only acceptable ones – Already existing federations in many domains – It is necessary to federate federations • edu. GAIN is the GÉANT 2 solution for this

edu. GAIN: AAI for GÉANT 2 Connect. Communicate. Collaborate • 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 Auth. N/Auth. Z must be properly handled by the participating federations – Dynamically established trust links

The perf. SONAR Model for Auth. N/Auth. Z Connect. Communicate. Collaborate • At each perf. SONAR participating domain there exists an instance of the Authentication Service (AS) – Acting as a proxy between the Auth. N/Auth. Z and the perf. SONAR 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 Auth. N/Auth. Z operations – AS takes resource access (Auth. Z) decisions on the basis of common domain policies • Though resources or resource protectors can ultimately deny access because of resource availability

The edu. GAIN Model Connect. Communicate. Collaborate • 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 edu. GAIN SAML-based profiles

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

Putting It All Together Connect. Communicate. Collaborate

edu. GAIN Operations Connect. Communicate. Collaborate • Defined in abstract terms, following the SOA paradigm – Metadata Service (MDS) – Authentication Service (Auth. N) – Attribute Exchange Service (Attr) – Authorisation Service (Auth. Z) • 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

edu. GAIN Operation Binding Connect. Communicate. Collaborate • 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

edu. GAIN Trust Fabric Connect. Communicate. Collaborate • 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

Component Identifiers Connect. Communicate. Collaborate • edu. GAIN operations strongly depend on having unique, structured and well-defined component identifiers • Based on URNs delegated by the edu. GAIN 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 edu. GAIN

The edu. GAIN API Connect. Communicate. Collaborate • Common libraries for all edu. GAIN components • Implementation of the edu. GAIN service definition, metadata access and validation procedures – The interface is based on specific classes modeling the abstract definition: Auth. NReq, Auth. NResp, … • Is a general abstraction layer for Auth. N/Auth. Z operations – Applicable to perf. SONAR clients and AS for interactions in the edu. GAIN trust zone – And to resources and other components for interactions in the internal trust zone

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

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

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 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 Id. P. Work is in progress to provide a simpler Alternative sequence Connect. Communicate. Collaborate

The GÉANT 2 Id. P (GId. P) Connect. Communicate. Collaborate • edu. GAIN 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ÉANT 2 services (including perf. SONAR) • GId. P fills a temporal gap – For those potential users of GÉANT 2 services that are within NRENs / end institutions without an AAI in place, or not yet connected to edu. GAIN • GId. P allows defining an initial trust and resource access model for GÉANT 2 services that can be refined/adjusted in the future.

GId. P: The “Home of Last Resort” for edu. GAIN Users accesses Connect. Communicate. Collaborate GId. P User authenticates GId. P p. SR H-BE Id. P R-AS R-BE edu. GAIN Resource’s Domain (Remote) Auth. N Attributes GId. P Domain (Home)

Where We Are • • • Connect. Communicate. Collaborate Implementing the edu. GAIN APIs Defining the GId. P service Polishing profiles First pilot to be run around 4 th quarter of this year Establishing links with other potential user communities – Inside GÉANT 2: JRA 3 (bandwidth-on-demand) and JRA 2 (security) – And beyond: the LOBSTER project • Starting an initiative to connect network access (eduroam) and AAI (edu. GAIN): DAMe

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