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

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

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

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

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

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

The eduGAIN Model MDS R-FPP H-FPP R-BE H-BE Resource(s) 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)

Putting It All Together Connect. Communicate. Collaborate Putting It All Together

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

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

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

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

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

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

A Layered Model eduGAIN API Profile logic 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

Profiles: Automated Client 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

Profiles: Client on Behalf of a User 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

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.

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

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

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