WS-Policy F2F Austin, TX July 2006 Report on WS-Policy Interop Workshop of April 2006 (Round 3) Toufic Boubez Layer 7 Technologies

WS-Policy F2F – July Logistics Host: SAP, Walldorf, Germany Dates: April 25-27, 2006 Participating companies: BEA, IBM, Microsoft, Layer 7, SAP, Sun, WSO2

WS-Policy F2F – July Purpose and Scenarios Purpose: To exercise substantial parts of the Policy Framework and Policy Attachment for WSDL in the context of a security policy domain; To ensure a shared understanding of the basic interoperability of the domain independent parts of the framework. Out of Scope: Acquisition of policy expressions; Cert exchanges; Round 1 and Round 2 testing.

WS-Policy F2F – July Round 1: Normalize, Merge and Intersect Normalize, Merge and Intersect exposed as WS operations. For example, Merge operation exchange: <s12:Envelope xmlns:s12=" xmlns:wsp=" > (... )+ <s12:Envelope xmlns:s12=" xmlns:wsp="

WS-Policy F2F – July Round 2: Computing Effective Policy Effective Policy computations exposed as WS operations. Operations take WSDL with Policy attachments and return effective policy for policy subject in normal form. Operations exposed are: EffectivePolicy4Input EffectivePolicy4Output EffectivePolicy4Fault EffectivePolicy4Operation EffectivePolicy4Endpoint EffectivePolicy4Service Service PortName OperationName

WS-Policy F2F – July Round 3 Configuration Simple echo Web service endpoint(s) exposed; Policy expressions attached to WSDL; Policy domain is WS-SecurityPolicy; WSDL provided out of band as part of the setup. One null scenario (test scenario - no policy); Two policy scenarios, with two test cases each: Scenario 1: Transport security policy Case T1: SSL with no client cert, Basic256Rsa15 as algorithm, timestamp required, no supporting UsernameToken; Case T3: Same as T1, but with UsernameToken appearing as SignedSupportingToken. Scenario 2: X509 security policy Case A11: X509v3 token, Basic256Rsa15, timestamp required, signing of body and header; Case A12: Same as A11, but with TripleDesRsa15 as algorithm.

WS-Policy F2F – July Echo Service WSDL <xs:schema targetNamespace=" blockDefault="#all" elementFormDefault="qualified" >

WS-Policy F2F – July Binding for Scenario 0: No Security

WS-Policy F2F – July Binding for Test Case T1

WS-Policy F2F – July Policy Expression for Test Case T1

WS-Policy F2F – July Policy Expression for Test Case T3: T1 + UsernameToken

WS-Policy F2F – July Binding for Test Case A11

WS-Policy F2F – July Policy Expression for Test Case A11 Binding

WS-Policy F2F – July Policy Expression for Test Case A11 Messages

WS-Policy F2F – July Policy Expression for Test Case A12: A11 with TripleDes

WS-Policy F2F – July Feedback No WS-Policy framework or WS-PolicyAttachment issues. Issues are mainly related to the practical specifics of the interop environment and security processing: Time synch: Certain clocks needed to be re-synched frequently throughout the day due to drift; conflicts about UTC local time. Whitespace: Line breaks and indentations in request SOAP Body causing problems for some toolkits (but only if the request was also encrypted).

WS-Policy F2F – July Clarifications and Observations WS-P: If assertion requires use of HTTPS transport level security and WSDL port address uses HTTP scheme, what is the recommendation? Should non-standard policy assertions be marked optional? There are behaviors that may be engaged for a Web service interaction. The provider will not fault if these behaviors are not engaged. These behaviors should be marked optional. For unrecognized assertions, tools should use a tolerant implementation strategy where they are consumed and designated for user intervention. The desire was expressed to create a more explicit description of the responsibilities and concerns between the policy framework level and policy assertion level. A primer would be a natural residence for this material. The desire was expressed to improve the readability of the fourth paragraph in section WS-Policy that describes the normalization rules for nested policy expression. WS-SP: WS-SecurityPolicy specifies default nested policy assertions. Should the provider explicitly state these assertions or be implicit? From intersection perspective at the policy framework level, these assertions must be explicitly stated to avoid false negatives. is an assertion parameter. Some suggested that it should be an assertion.

WS-Policy F2F – July Client/ ServerP1P2P3P4P5P6P7 P1 NoSe c T1 T3 A11 A12 P2 NoSe c T1 T3 A11 A12 P3 NoSe c T1 T3 A11 A12 P4 NoSe c T1 T3 A11 A12 P5 NoSe c T1 T3 A11 A12 P6 NoSe c T1 T3 A11 A12 P7 NoSe c T1 T3 A11 A12 Results