Frascati, December 2009 Slide 1 Identity Management in ESA Grid on-Demand Infrastructure HMA-T Final Presentation 14 December 2009, Frascati Fabrice Brito & Andrew Woolf

Frascati, December 2009 Summary  ESA G-POD Infrastructure  Review of proposed tasks  Review of Deliverables  CITE Tests on the G-POD submission tool  Impact assessment of OGC version  Closed Actions

Frascati, December 2009 G-POD  Enhance the ability to create high level products and single stop shop for data access and processing  Support Industry and Research in service and science developments  Allow processing of large historical archives and near real- time data  e-collaboration (sharing of data sources, tools, models, algorithms) and improve Earth science complex applications (data fusion, data mining, modeling …)

Frascati, December 2009 G-POD Usage  Provide a “user-segment” environment Putting data & processors together allows “on-demand” processing  Offer scientists a “production lab” Focus on algorithms and reuse housekeeping functions (e.g. catalogue, software tools) Bridge gap from “prototype” to “production” processor  Offer scientists a “collaboration” environment Share tools and functions, reuse output of other processors (IPR is kept by the scientist) move processors close to the data reduce dissemination costs and effort evolutions benefit to all at once  Grid as a common shared platform for collaborations in scientific domain and routine operations environment

Frascati, December 2009 Slide 5 ESA G-POD Infrastructure  Computing and Storage Elements Working Nodes, +120 TB on-line store Middleware: GLOBUS 4, (and some exp in gLite3) Links to external CE and SE (e.g. CNR, EGEE)  Data Interfaces GS products Rolling Archives (ENVISAT, MSG) and MODIS NRT products over Europe + NASA and other external data providers  Software resources on-line IDL, Matlab, BEAT, BEAM, BEST, NEST, BRAT, CQFD, Compilers, public domain image processing utilities Spatial Catalogue access (e.g. EOLI) and data provision functions  web portal and web services access powered by gridify, maintenance and evolution under Terradue responsibility

Frascati, December 2009 Examples - Routine Production MERIS Level-3 Products NRT generation  Joint ESA collaboration with ACRI (France), JRC/Ispra (European Commission) and Brockmann Consult (BEAM). Monthly products published on-line Daily ASAR GM mapping of Antarctica  Daily Generation of 400-m resolution mosaics publish on WMS (in operations since 2005) ASAR on Demand  Integrated environment for SAR processing binds separate functionality into applications (flood monitoring, co-registration, etc) Volcanoes Monitoring by Infrared (AATSR) with extraction of thermal anomalies Monthly MERIS True-Color Mosaics Slide 6

Frascati, December 2009 G-POD Web Services Interface

Frascati, December 2009 G-POD User Management  Based on the Grid Security Infrastructure (GSI) Secure communications between elements of a computational Grid Security across organizational boundaries Includes delegation of credentials for computations that involve multiple resources and sites Identity management interfaces based on the use of proxy certificates (MyProxy)  This work package had the objective of improving the harmonization of the authentication and authorization approaches with HMA Evaluate and prototype the integration of the G-POD in a federated structure of ground segments and processing centres with common authorization interface

Frascati, December 2009 HMA-T G-POD (OGC )

Frascati, December 2009 Tasks  Harmonization of auth/N and auth/Z between ESA Grid Infrastructure (G-POD) and HMA  Assess the potential of in the ESA Grid infrastructure  Prototype SOAP implementing integrated in G- POD (reference using EODAIL IdP HMA-T/G-POD Web Service and Web Service Client (CLI)  Design conformance test scripts and test pages on the OGC CITE test environment

Frascati, December 2009  ATS and ETS  STFC Tech. Note - HMAT-TN-0001-STFC-T2 User Management Technical Note v0.1 (additional deliverable) download_wiki_attachment.php?attId=543&download=y download_wiki_attachment.php?attId=543&download=y Deliverables

Frascati, December 2009 OGC version (1/2)  Improved from earlier versions: simplification (e.g. removed ‘Orchestrating Service Provider’) new authentication sequence (compared with 0.0.4): direct to Service Provider having its own IdP provides much greater detail about possible implementation of authorisation policy (e.g. using XACML)

Frascati, December 2009 OGC version (2/2)  New ATS structure: M1: Basic tests (SOAP, SAML, encryption, digital signature, removed combined encryption/signature test) M2: Authentication (default Federating Entity IdP, Federating Entity IdP, External Entity IdP, authentication failure, removed default External Entity IdP) M3: Service request/authorisation (synchronous, asynchronous, authorisation failure)  Issues WS-Addressing use still not well described Spec still refers explicitly just to ordering/programming/catalogue digital signature (see later slides, and TN)

Frascati, December 2009  Worked with Intecs (lead) as agreed at AR STFC provided input, reviewed and tested STFC provided ETS Team Engine code to Intecs (java security code, file handling, asynchronous request polling etc.) now one common ETS  Note: EO-DAIL still doesn’t support HM service requests Continue to use a ‘proxy’ approach:  obtain encrypted SAML token from IdP  decrypt token at client (TEAM engine) using ‘cached’ IdP private key  encrypt service request at client using end service public key CITE Tests (1/4)

Frascati, December 2009 CITE Tests (2/4)  ETS implementation (follows ATS): WS-Security module: ATC-1.1 (SOAP binding), ATC-1.2 (SAML GMES profile), ATC-1.3 (encryption – now as per STFC approach, as agreed at AR), ATC-1.4 (digital signature) Authentication module: ATC-2.1 (Federating entity is default IdP), ATC-2.2 (Federating entity is request-designated IdP), ATC-2.3 (External entity is request-designated IdP), ATC-2.4 (Authentication request failure) Authorisation module: ATC-3.1 (synchronous request), ATC-3.2 (asynchronous request – not implemented since not complete, next slide), ATC-3.4 (authorisation failure) Slide 15

Frascati, December 2009 CITE Tests (3/4)  Concerning asynchronous requests there are two sets of remaining issues Specification issues  is not clear on details of how WS-Addressing should be used –presumably wsa:ReplyTo should be used for response endpoint –what about faults – separate endpoint? –what about firewalls etc. – ‘anonymous’ endpoint?  ATC-3.2 (asynchronous) –“NOTE: This abstract test case is still under finalization” –therefore also not implemented in ETS Implementation issues  TEAM engine: requires new architectural feature – an endpoint for asynchronous responses –at minimum, requires inbuilt ‘http server’ (Note previously STFC ETS used ‘polling’ approach) Slide 16

Frascati, December 2009  Test results (WS-Security): ATC-1.1: SOAP binding (IdP and SP) ATC-1.2: SAML encoding for authentication token ATC-1.3: AES-128 encryption used ATC-1.4: SHA-1 signature digest used  Test results (authentication): ATC-2.1: Federated IdP (local identification resolved by default) ATC-2.2: Federated IdP (local identification specified) ATC-2.3: External IdP specified ATC-2.4: SOAP fault on invalid login  Test results (G-POD authorisation): ATC-3.1: Synchronous request ATC-3.2: Asynchronous request (empty test because ATS not finalised) ATC-3.3: Authorisation failure (‘commercial’ CITE Tests (4/4)

Frascati, December 2009 CLOSED Actions  A25 -> Analyse new OGC expected from DAIL project in october 2008 spec analysed; ATS/ETS developed (jointly with Intecs) as described above  A204 -> ATS 1.3 to be changed to test the actual encryption algorithm and not only check the WSDL. Done – new CTL does this for ATC-1.3  A207 -> Provide real test for checking encryption algorithm and not WSDL STFC provided ATC-1.3 code to Intecs, who incorporated this in the implementation  A208 -> Align ATS/ETS:CTL with version of OGC Done in collaboration with Intecs

Frascati, December 2009 Future Directions  still needs clarification on WS-Addressing standardise failure reporting (both authn/authz) – needed for automated workflows digital signature (CanonicalizationMethod,  TEAM Engine issues Asynchronous polling (with CTL changes), WS-Addressing XPath function () vs. CTL (bug?)  Clarify the relation and evolution regarding the ESA SSO activity  Adoption of on G-POD still needs to be clarified Meeting with SSO team in a future date ref. Tech Note from STFC

Frascati, December 2009 Slide 20 Thank you!