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

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

Connect. Communicate. Collaborate 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

Connect. Communicate. Collaborate 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

Connect. Communicate. Collaborate 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

Connect. Communicate. Collaborate 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

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

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

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

Connect. Communicate. Collaborate 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

Connect. Communicate. Collaborate 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

Connect. Communicate. Collaborate 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

Connect. Communicate. Collaborate 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

Connect. Communicate. Collaborate 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

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

Connect. Communicate. Collaborate Profiles: Automated Client Connect. Communicate. Collaborate 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 Connect. Communicate. Collaborate 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

Connect. Communicate. Collaborate 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.

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

Connect. Communicate. Collaborate 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

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