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

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

3. WS-Policy F2F – July 2006 3 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.

4. WS-Policy F2F – July 2006 4 Round 1: Normalize, Merge and Intersect Normalize, Merge and Intersect exposed as WS operations. For example, Merge operation exchange: <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > (... )+ <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">...

5. WS-Policy F2F – July 2006 5 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

6. WS-Policy F2F – July 2006 6 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.

7. WS-Policy F2F – July 2006 7 Echo Service WSDL <xs:schema targetNamespace="http://example.com/ws/2004/09/policy" blockDefault="#all" elementFormDefault="qualified" >

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

9. WS-Policy F2F – July 2006 9 Binding for Test Case T1

10. WS-Policy F2F – July 2006 10 Policy Expression for Test Case T1

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

12. WS-Policy F2F – July 2006 12 Binding for Test Case A11

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

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

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

16. WS-Policy F2F – July 2006 16Feedback 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).

17. WS-Policy F2F – July 2006 17 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 4.3.2 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. sp:HttpsToken/@RequireClientCertificate is an assertion parameter. Some suggested that it should be an assertion.

18. WS-Policy F2F – July 2006 18 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