1. Identity Management in ESA Grid on-Demand Infrastructure
HMA-T Acceptance Review
16 July 2009, Frascati
Pedro Pereira Gonçalves
Slide 1

2. 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 0.0.4
Use of OGC “hma” SVN
Open Actions

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

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

5. ESA G-POD Infrastructure
Computing and Storage Elements
+ 200 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, 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
Slide 5 5

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

7. G-POD Web Services Interface

8. 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 has 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

9. HMA-T G-POD (OGC )

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

11. Deliverables Review of the Architecture Document
Administration and User Manual
Web Service ICD
Acceptance Test Plan and Acceptance Test Report
ATS and ETS

12. Use OGC svn
Problems of change control, coordination between participants, version synchronisation
e.g. CITE TEAM Engine SOAP enhancements
svn is a very good solution
very easy to use, esp. with user-friendly clients like TortoiseSVN
However, now several collaborative tools, working spaces
SSE wiki (for endpoints, CITE test results)
OGC svn (for ETS CTL scripts)
sourceforge (for TEAM Engine)
Recommend: bring all of these together in one place
Main conclusion here is that there are tools in too many different places, but in general svn Is Good!

13. OGC 07-118 version 0.0.4 (1/2) Main changes:
Authentication use cases simplified (IdP is named, or (default) Federating Entity, i.e. EO-DAIL)
Authorisation use cases distinguished only by response (no separate synch/asynch authz scenarios)
WS-Security profile – SAML tokens signed before encrypted (UML sequence diagrams and text are now consistent)
Proposed new ATS structure:
M.1 (WS-Security): no change (remove WS-Security on WSDL?)
M.2 (Authentication): external IdP, default IdP, authn failure
M.3 (Authorisation): no change (but update test details)
The main changes are:
simplified authn cases - either a named IdP within a federation, or else the default federating entity (previously allowed finding where the user was based amongst a federation if a specific IdP not named)
no separate authz scenarios making a distinction between ‘asynch’ or ‘synch’ *services*, now its just the response that is identified as synch or asynch
encryption/signing order changed when making a call to end service (e.g. G-POD)
Based on this, we would propose a new ATS structure:
no change to WS-Security tests (although two of these concern checking the IdP WSDL to see if it advertises support for encryption and signature – I’m personally not greatly convinced by this since this requirement on the WSDL isn’t explicitly part of ; also the current IdP would fail since there is no WS-Security stuff mentioned in its WSDL)
simplify authn tests to just three – named IdP, no named IdP (assumed to be default federating entity), failure (i.e. incorrect login details)
authn – no change

14. OGC 07-118 version 0.0.4 (2/2) Other comments:
ATS refers to ‘Orchestrating Service’, but role unclear in with respect to ‘Federating Entity’
The ‘DAIL HM Service’ and generic ‘Service Provider’ are used interchangeably, consistent terminology should be adopted
The role of WS-Addressing is not explained in asynchronous interaction sequences (but used in 7.3.3)
While UM not limited to ordering/programming/catalogue, these are referred to explicitly in 7.3 (authz response)
Some editorial (proposed changes)
6.2: “For authorisation requests, all authentication tokens shall be in the WS-Security element in the header of the SOAP envelope”
: “...the authentication request lacks an identifier specifying an external IdP”
ETS needs more work once EO-DAIL support is implemented

15. CITE Tests (1/3) EO-DAIL doesn’t yet support HM service requests
Implemented a ‘proxy’ approach:
obtain encrypted SAML token from IdP (EO-DAIL, using ‘TestUser’)
decrypt token at client (TEAM engine) using ‘cached’ IdP private key
encrypt service request at client using G-POD public key
ETS implementation (follows ATS):
WS-Security module: ATC-1.1 (SOAP binding), ATC-1.2 (SAML GMES profile), ATC-1.5 (SAML encrypted & signed)
not implemented: ATC-{1.3,1.4} (IdP WSDL decorated with WS-Security)
Authentication module: ATC-2.3 (Federating entity is default IdP), ATC-2.5 (SOAP fault on invalid login)
not implemented: ATC-{2.1,2.2,2.4} (federated IdPs)
G-POD extension module (encompasses ATS authorisation tests): SubmitExt, Status, Results

16. CITE Tests (2/3)
Extended TEAM Engine with custom Java security classes
done in parallel with Intecs due to time constraints, thus no common ETS at present
Java functionality: decryption/encryption (AES-128), signature validation, signing (SHA-1), complex XML checking (e.g. GMES SAML verification in Java code rather than CTL), utilities (temp files, sleeping for asynch polling)
For authorisation (service request), followed sequence (§ , Figure 6): encryption followed by signature
Reversed in 0.0.4, also in ATS

17. CITE Tests (3/3) Test results (WS-Security):
ATC-1.1: SOAP binding
ATC-1.2: SAML GMES profile
ATC-1.5: SAML encryption, signature
Test results (authentication):
ATC-2.3: Login at federating entity
ATC-2.5: SOAP fault on invalid login
Test results (G-POD):
EXT_submit_1: SubmitExt (with authz)
EXT_status_2: Status (with authz)
EXT_result_3: Results (with authz)

18. Open Actions
A3 - Align conformance classes to take into account proxy implementations
A8 - Verify and clarify use of explicit policy rules using XACML
XACML can’t be used currently. TBC in future G-POD evolutions
A9 - Clarify whether architecture assumes list of users in HMA are same as known in G-POD user database
If unknown then HMA IdP user is dynamically recognized

19. Open Actions A12 - Provide RIDs on UM ICD (07-118 version 0.0.3)
CLOSED (See A25 discussion)
A14 - Propose a single ATS document for UM ICD and collaborate on ETS
CLOSED (NOTE: Different Java security extensions for TEAM Engine developed independently due to different timescales)
A16 - Contact Intecs to define how to do a demonstration using Toolbox support
IN PROGRESS

20. Open Actions
A25 - Analyse new OGC expected from DAIL project in October 2008
HM Service invocations expected to go via Federating Entity (decrypts SAML token before passing to Service Provider)
This is not currently implemented in EO-DAIL
Would it be possible requests direct from User → Service Provider (Issues: end user public key, SAML ConfirmationMethod bearer vs. holder-of-key)
More fine-grained authorisation failure reporting could be considered
e.g. expired SAML token, invalid SAML token, service use not authorised, specific service request not authorised
: “The full fault list remains TBD”, removed in but still TBD!
Asynchronous request interactions needs much more work
WS-Addressing mentioned but no usage patterns described
Handled in G-POD through traditional client polling

21. Thank you
Slide 21

22. ##
###