1. Wednesday, 3:30 PM – 5:00 PM Telecom SOA Profile  WS Addressing  WS reliable messaging  WS security  SOAP over JMS  General improvement of specs with guidelines to avoid proliferation of solutions  WS-Policy

2. 2 Potential standards under analysis  OASIS Standards:  WS-* (Reliability, Security, Transaction)  WS-T includes: WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity  WS-Reliable Messaging  BPEL (Business Process Execution Standard)  UDDI (Universal Description, Discovery and Integration)  WSDM (Web Services Distributed Management)  WS-Notification ...  non-OASIS Standards  WSDL (Web Services Description Language), W3C  WS-Addressing, W3C  SOAP (Simple Object Access Protocol ) W3C / IETF  WS-Policy  W3C Web Services Resource Access WG (WSRA WG ) ...

3. 3 Some hints for discussion (and possible TI contributions)  WS-Reliable Messaging (WS-RM)  Backward compatibility of WS RM standards  From internal trials with specific vendors we have realized that products declaring compatibility to different versions of WS Reliable Messaging 1.0 (revision 2004 e 2005) (BEA WLS vers. 8.1 and Sonic ESB vers. 7.5) were not interoperable  Suggested action: impose that WS-RM Standards (and more general OASIS standards) are backward compatible.  WS-Addressing (WS-A)  Case: if more “systems” interact for the execution of a business process which has an “entry point web service” the last system in the chain must be put in the condition of knowing where to send the final asynch response.  Possible extension of the WS-A specification in order that the “Message Properties” include a new tag (provisionally named “Final Destination”) to specify the process/transaction result.  Draft contribution can be shared  WS Security (WS-S)  WS-sec Header management  SAML token invalidation  WS-Notification  A standard for the management of notification subscriptions is missing, IMB attempt …

4. 4 WS-sec Header management  Context  We have a SOA infrastructure, made by an ESB, a security server, some security enforcement points (SEPs), some services (system) consumers, some services (system) providers.  (All the elements are in a company protected IT environment – intranet -, but that isn’t relevant for the following use case).  The company security policy is based on the Ws-security protocol (the specific security model is not important)  Use Case:  A service consumer invokes a Web Service, the service is published by the ESB, but it is accessible only by a SEP.ESBService ProviderSEPSecurity Server1234  The SOAP message contains a WS sec header.  The service consumer invokes the SEP.  The SEP authenticates and authorizes the service consumer.  The SEP forwards the message to the ESB; the SEP does not make any change to the message.  The ESB should accept the message without any security check, and forward this to the service providers.  Technical issue:  Although the ESB was configured with WS security protocol disabled, if the SOAP message contains a WS security header, the ESB tries in any case to understand and tries to process the Ws security header.  The ESB couldn’t authenticate and authorize the message (for example because it is not in possession of the consumer certificates) because the SEP makes that.  Result: the ESB raises an exception and then stops the transaction.  Suggestions to address the issue:  The WS security specification should force that any actor (receiver, intermediary, other) if correctly configured, could be able to receive and/or forward a SOAP message without understanding and processing this header. ESB Service Provider SE P Security Server 12 3 4

5. 5 SAML token invalidation  Scenario/context:  We have a SOA infrastructure, made by an ESB, a security server, some security enforcement points (SEPs), some service (system) consumers, some service (system) providers.  (All the elements are a protected IT environment of the company, but that isn’t relevant in the following use case).  The company security policy is based on the Ws-security protocol, in particular on the SMAL Assertion protocol.  Use Case:  A service consumer invokes a Web Service;  the service invoked is published by the ESB and consists of two basic services;  the ESB first invokes the service 1 and then the service 2;  every service is accessible only by a SEP;  the service consumer or the SEP (through the Security Server) generates a SAML assertion.  the service consumer invokes the SEP 1;  SEP1 authenticates, authorizes the service consumer and generates a SAML token;  SEP1 forwards the message + the SAML assertion to the ESB;  ESB forwards the message to SEP 2;  SEP 2 validates the SAML token and authorizes the service invocation;  SEP 2 forwards the message to SP1;  SP1 replies to ESB (possibly through another SEP);  ESB forwards the message to SEP3;  SEP 3 validates the token and forwards the message to SP2;  the transaction ends.  Technical issue:  The SAML expiration time could be much longer that the transaction completion time, it could be necessary a long expiration time for some reasons, for example to manage the request iterations due to communication failures.  The SAML expiration time after the transaction completion could be a weakness element of the security architecture.  The SEP 3 is aware that the transaction is ended (after the SP 2 invocation), so it should be possible for the SEP 3 to explicitly invalidate the SAML assertion;  Suggestions to addressing the issue:  The WS security specification should make possible to explicitly invalidate a SAML token. ESB SP1 SEP 1 SP 2 Security Server 1 2 3 4 SEP 2 6 7 SEP 3 10 8 5 9

6. 6 SOAP  SOAP header propagation (Intermediary / Ultimate Receiver …)  “The SOAP receiver that is a final destination of a SOAP message is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message” - SOAP Version 1.2 Part 1: Messaging Framework - W3C Recommendation 24 June 2003  From the text it emerges that:  Only the intermediary propagates SOAP Headers  the SOAP body is processed by the final destination  The final destination can not itself be a SOAP intermediary (and thus propagate again the SOAP Headers) for the same SOAP message  Within the TI SOA Architecture the ESB (or better, the WS exposed by the ESB) is the final destination (Ultimate SOAP Receiver) because it processes the SOAP Body in order to apply the required logics. It is NOT a SOAP intermediary  It would be important to correct such ambiguity within specifications: it is not possible that an ESB can not propagate a SOAP header, because it can elaborate and enrich the message and it must be considered a SOAP receiver and not an intermediary.

7. 7 Other hint SOAP over JMS: standardization proposal  The requirement of certified delivery of the message (Once&OnlyOnce), indispensable for many backend applications (CRM, GISP, EAIMM), can be satisfied on HTTP protocol only with WS-RM which “heavies” communication  An alternative is the usage of a protocol such as JMS in which the delivery mechanism is implicit, but there is the problem that it is not yet adopted by W3C/OASIS as the standard for the SOAP binding  moreover JMS, being natively asynchronous, does not need WS-A and prevents systems to remain in session wating for responses, with evident advantages on resources locking  A standard common framework could be proposed for interoperability on JMS protocol (AXIS – Apache Extensible Interaction System )  Moreover JMS offers another advantage: “transactionality” on the protocol, i.e. the possibility to participate to XA transactions

8. 8 General messages  Specifations enrichment with patterns/models to optimize standard applications  Introduction of some “examples” to make specifications more understandable and less “interpretable”