3a3504b5e7a260d026a5321fe24a2405.ppt
- Количество слайдов: 21
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
3a3504b5e7a260d026a5321fe24a2405.ppt