1. Web Service Security support in the SSE Toolbox
HMA-T Phase 2 CDR Meeting
18-19 February 2009
S. Gianfranceschi, Intecs
Slide 1

2. Agenda Introduction Work performed
Toolbox Security Architectural Overview
ATS and ATP Overview
Work planned
Schedule
Open discussion
Slide 2

3. Agenda Introduction Work performed
Toolbox Security Architectural Overview
ATS and ATP Overview
Work planned
Schedule
Open discussion
Slide 3 3

4. Introduction
The Toolbox is a framework which facilitate the integration of web services in the HMA infrastructure.
The component that will be provided in this project is finalized of providing WS-Security at Ground Segment level, enabling existing GS to wrap and connect their own catalogues to the HMA infrastructure.
Both internal (deployed on the Toolbox) and external (gateway) services can be secured with this extension.
Slide 4

5. HMA Infrastructure high-level diagram
Slide 5

6. Agenda Introduction Work performed
Toolbox Security Architectural Overview
ATS and ATP Overview
Work planned
Schedule
Open discussion
Slide 6 6

7. Work Performed Upgrade of the prototype for the security layer
Integration of the prototype in the Toolbox (started)
Architectural Design Document: first release
Development of sample XACML policy files for EbRim EO profile interfaces.
Requirement Document: new release
ATS and ATP: first release
Slide 7

8. Requirements RID Description Action
Requirement document: new version available (HMAT-SRD-1200-INT_1.1)
New/update requirements from RIDs:
RID
Description
Action
YC-59
“Would be highly desirable that also SOAP 1.1 is supported via a configuration parameter as SOAP 1.1 is the current EODAIL baseline.”
Requirement HMAT-RB-INT- 010 updated accordingly (chapter 3.3, pag. 19)
YC-61
Regarding SAML token attributes: “the Toolbox should support a configurable list instead of this Fixed list; as the list in is only indicative…".
Requirement HMAT-RB-INT- 120 modified accordingly (chapter 3.3, pag. 21)

9. Agenda Introduction Work performed
Toolbox Security Architecture Overview
ATS and ATP Overview
Work planned
Schedule
Open discussion
Slide 9 9

10. Application Security Layer
Toolbox Architecture
WS-Policy
WS-Security Layer
SOAP layer
Application layer
XACML Policy
Application Security Layer
Service
Gateway
Operation
Operation
Asynchronous Operation
Synchronous Operation
Asynchronous Operation
Synchronous Operation

11. Toolbox Security Architecture
Axis2 as basic SOAP engine
Axis2 module Rampart (Apache Software Foundation) for WS-Security layer: its behaviour has been extended to cover the HMAT security requirements (HMAT- SRD-1200-INT_1.1)
ToolboxSecurityWrapper: Axis2 service with link to the Policy Enforcement Point (PEP, Application Security Layer) and Toolbox Application Layer
Axis2
ToolboxPEP
ToolboxSecurityWrapper
(Axis2 service)
SOAP
XACML Policies
Service
Description
RAMPART
4HMAT
Toolbox Application Layer
WS-Policy

12. Toolbox Security Architecture: Main Activities Allocation
Security Layer 1 2
Verify client signature, decryption of SAML token
WS-Security signed-encrypted SOAP request 3
Enforce enterprise policies
Toolbox
Serve request (Application layer) 4 5
Fault Soap response
verify SAML token
SAML attributes 6
Get SAML assertion
Identity Provider
Client
ToolboxPEP
RAMPART
4HMAT
WS-Policy
XACML Policies
Slide 12

13. Toolbox Security Architecture
A more formal model:

14. Toolbox Security Wrapper: Service Description
Axis2
Responsabilities:
deploys ToolboxSecurityWrapper into Axis2,
holds the list of the wrapped services to be secured,
for each wrapped service, holds the WS-Security policy,
Its artifact is the service.xml file of the Axis2 ToolboxSecurity deployment located at:
ToolboxSecurityWrapper
(Axis2 service)
RAMPART
4HMAT
Service
Description
Service
Configuration
WS-Policy
<TOMCAT_ROOT>/webapps/Axis2/Web-INF/services/ToolboxSecurityWrapper/META-INF/services.xml

15. Service Description: an Example
Wrapped Service
Wrapper service
SOAP action
WS-Security policy

16. Toolbox Security Architecture: ToolboxPEP
ToolboxPEP: invoked by the ToolboxSecurityWrapper when WS-Security check is successful; enforces XACML policies check
XACML policies are stored in dedicated XML files
Each policy
owns information about the wrapped service and SOAP action for which the policy applies
Owns a list of policy rules; each rule can refer SAML token and/or SOAP (body) attributes values.
ToolboxPEP
XACML Policies

17. XACML example for EO EbRim profile (1/3)
The target wrapped service for which this policy applies: wrs (Web Registry Service)

18. XACML example for EOLI (2/3)
If an owned condition evaluates to true than the effect of the rule is “deny”
The target of this rule: commercial client
SAML attribute reference
Condition about the collection

19. XACML example for EO EbRim profile (3/3)
SOAP action for registry update

20. Agenda Introduction Work performed
Toolbox Security Architecture Overview
ATS and ATP Overview
Work planned
Schedule
Open discussion
Slide 20 20

21. TEST PLAN Test Plan is made up of 2 main building block:
Abstract Test Suite for OGC r1 (ATS in brief)
Acceptance Test Plan for Toolbox Security Layer specific aspects
ATS delivered as a separate document
A unique ATS, merging multiple contributions, shall be defined
The ATS format and structure harmonized at the OGC level
The ATS has to be “instantiated” in an ETS (Executable Test Suite)
ATP “complements” ATS
E.g. non functional requirements, SW/HW specific aspects.
Slide 21 21

22. ATS - 1 ATS addresses conformance tests
The aim is to check that a service/product fulfills the clauses of an OGC Implementation Specification
HMA-T services are tested against OGC r1 “clauses” covering authentication and authorization interfaces for EO products
ATS is usually structured according to class levels
Mandatory elements are at the bottom conformance class level
Classes shall be defined at the specification level, otherwise a unique core conformance class with all clauses is assumed
For OGC a unique conformance core class is defined
Slide 22 22

23. ATS - 2 ATS main aspects: ATS proposed structure:
Authentication capabilities provided by Identity Providers
Authorization aspects enforced by Service Providers
ATS proposed structure:
Module 1 for clauses addressing common protocols/specifications used
Module 2 for authentication conformance tests
Module 3 for authorization conformance tests
Slide 23 23

24. ATS – Module 1 ATS Module 1 Tests for Module 1 encryption issues:
Support for SOAP/HTTP or SOAP/HTTPS
SOAP version 1.2 in OGC > 1.1 in new spec.
Support for SAML token
Embedded in WS-Security elements in SOAP header
Covering GMES minimum profile
Support for encryption/hashing
AES-128 encryption algorithm and SHA-1 hash algorithm for signature
Tests for Module 1 encryption issues:
SAML Token encrypted with public key of the Federating Entity
SAML Token contents cannot be accessed without private key
Slide 24 24

25. ATS – Module 1
Suggestion 1: inspect the wsdl to check support of security features
WSDL should be extended with WS-policy description (in line with OASIS policy)
Not applicable for checking SAML support of minimum profile
Suggestion 2: test session with the IdP
Self-generate a couple of key for testing
Invasive: both Identity Provider and Service Provider (sharing private key) are involved
Slide 25 25

26. ATS – Module 2 ATS Module 2 Tests for ATS Module 2 issues
Support for authentication requests
Explicit designated IdP
Federating entity
External entity
No IdP designated
Federating entity plays as the IdP
External entity plays as IdP
Tests for ATS Module 2 issues
As in Module 1
Being related to Identity Provider capabilities, the Toolbox Security Layer ETS will not address this Module
Slide 26 26

27. ATS – Module 3 ATS Module 3 ATS Module 3 issues
Support for authorization requests
Synchronous mode
Asynchronous mode
ATS Module 3 issues
Asynchronous behavior depends on the specific implementation service
Authorization failures still need to be defined
Slide 27 27

28. STS The ATP covers also the following scenarios
Scenario TS_1
Configuration of WS-Security policy
Configuration of XACML policy
Scenario TS_2
Protocol bindings not covered in OGC r1 v0.0.2
Future issues of the document:
ETS for data and definition of actual test cases covered by ATS
Input data for remaining ATP test cases
Slide 28 28

29. Agenda Introduction Work performed
Toolbox Security Architectural Overview
Work planned
Schedule
Open discussion
Slide 29 29

30. Work planned Architectural Design Document: final version
Toolbox integration finalization
Manage asynchronous response: from OGC “ the response has to be signed”
ATS and ATP finalization
ETS preparation
Test
Slide 30

31. Agenda Introduction Work performed
Toolbox Security Architectural Overview
Work planned
Schedule
Open discussion
Slide 31 31

32. Schedule

33. Agenda Introduction Work performed
Toolbox Security Architectural Overview
Work planned
Schedule
Open discussion
Slide 33 33

34. SOAP Support in the TEAM Engine
HMA-T Phase 2 CDR Meeting
18-19 February 2009
S. Gianfranceschi, Intecs
Slide 34

35. TEAM Engine story
First version in July available on the ERGO WIKI pages
Based on AXIS SOAP client
No access to the SOAP and HTTP level
Discussion with OGC in September
A new structure of the tag has been agreed
A prototype compliant with the new tag structure has been done
No feedback from OGC
New contacts with the OGC in February
No work on SOAP support has been done by OGC
Major changes have been done on the TEAM Engine by OGC to cope with performances.
A synchronization is needed
Slide 35

36. TEAM Engine A new prototype for the Team Engine has been developed
New tag sysntax
No specific SOAP client
Allow access to the HTTP layer
New SOAP parser
The work done have to be aligned with the current version of the TEAM Engine (available only on SVN, Team2 branch).
Slide 36

37. OLD structure <soap-request Required The SOAP request instruction
returnType=”XML|SOAP”>
Define the structure of the return XML message. If SOAP, the complete SOAP message is returned (including the SOAP tags). If XML, the content of the SOAP body is returned.
<url>URL</url>
Requested web resource
<soapaction>soapaction </ soapaction >
SOAP action for the request. It has to be compliant with the end point WSDL description.
<body>XML </body>
Body for the SOAP Request. It has to be compliant with the end point WSDL description.
<parser/>
Optional
Parser instruction needed to validate the content of the SOAP message. If not provided the tag returns directly the content of the SOAP message without validation.
</request>
Slide 37

38. NEW Structure <soap-request Required The SOAP request instruction
version="1.1|1.2">
Define SOAP version to be used. In the current implementation only 1.1 is supported.
<url>URL</url>
Requested web resource
<soapaction>soapaction</ soapaction >
Optional
SOAP action for the request. It has to be compliant with the end point WSDL description. If not provided an empty Sopa Action will be used.
<headers>
Header for the SOAP request.
<element/>
Elements to be included in the SOAP Header
< headers />
<body>XML </body>
Body for the SOAP Request. It has to be compliant with the end point WSDL description.
<parser/>
Parser instruction needed to validate the content of the SOAP message. If not provided the tag returns directly the content of the SOAP message without validation.
</request>
Slide 38

39. OLD example <soap-request returnType="XML">
<url><xsl:value-of select="$GetRecordsURL"/></url>
<soapaction>GetRecords</soapaction>
<body>
<csw:GetRecords>
...
</csw:GetRecords>
</body>
<ctlp:SOAPXMLValidatingParser ignoreErrors="true" ignoreWarnings="true" xmlns:ctlp="
</soap-request>
Slide 39

40. NEW Example <soap-request version="1.1">
<url><xsl:value-of select="$GetRecordsURL"/></url>
<soapaction>GetRecords</soapaction>
<body>
<csw:GetRecords>
...
</csw:GetRecords>
</body>
<parsers:SOAPParser return="body">
<parsers:XMLValidatingParser>
<parsers:schemas>
<parsers:schema type="url">
</parsers:schemas>
</parsers:XMLValidatingParser>
</parsers:SOAPParser>
</soap-request>
Slide 40