1. Applying eduGAIN to network operations The 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. 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)

8. Putting It All Together
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. 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

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

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

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

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. Time for Your Questions (and Your Applause)
Connect. Communicate. Collaborate
Time for Your Questions (and Your Applause)