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

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

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

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

HMA Infrastructure high-level diagram Slide 5

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

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

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 07-118 is only indicative…". Requirement HMAT-RB-INT- 120 modified accordingly (chapter 3.3, pag. 21)

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

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

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

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

Toolbox Security Architecture A more formal model:

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

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

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

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

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

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

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

TEST PLAN Test Plan is made up of 2 main building block: Abstract Test Suite for OGC 07-118r1 (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

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 07-118r1 “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 07-118 a unique conformance core class is defined Slide 22 22

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

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 0.0.2 -> 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

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

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

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

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 07-118r1 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

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

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

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

Schedule

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

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

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

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

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

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

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="http://www.occamlab.com/te/parsers"/> </soap-request> Slide 39

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">http://www.oasis-open.org/committees/regrep/documents/3.0/schema/rim.xsd</parsers:schema> </parsers:schemas> </parsers:XMLValidatingParser> </parsers:SOAPParser> </soap-request> Slide 40