Book review: SOA Security

Recently, a new book on Web Services Security was published: SOA Security. While on holiday in beautiful Italy, I went through the book. Obviously the book starts with some introduction on SOAP, WSDL and the like. But the major part of the book explains in quite some detail how to implement secure web services using JAX-RPC and Axis.

Two parts were most interesting to me personally. First of all chapter 4 and 5 on Kerberos and the "Secure Authentication with Kerberos": it was a joy to get a refresh on Kerberos, see some sample code using JAAS and GSS API's and see code snippets implementing the Kerberos Token Profile. And secondly Chapter 8 "Implementing security as a service": the different models in which web services can leverage SAML are well explained. Also the relationship with WS-Trust is made.

Sometimes I got the impression that the base material was written some time ago before being published. E.g. it is a pitty that the samples are based on JAX-RPC and Axis. Axis2 or JAX-WS would been better choices. Still, the book is OK, and don't be misled by the sample chapters online which are quite basic. But I keep hoping that one day, a 2nd edition of "Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption" will appear.

Note: it is clear that the authors have been working with or for CISCO as they use the CISCO specific acronym AON instead of XML gateway or similar

Free SOA books online

A couple of interesting SOA books can be freely accessed via pdfchm, a cheap alternative to Safari.

CapeClear

While accessing the blog of Annrai O'Toole, CEO of CapeClear, I learned that CapeClear was acquired by Workday. This already happened back in February, but it didn't get that news.

Remember well when CapeClear was one of the 1st vendors with a commercial SOAP stack. They even shipped me their 1.0 trial version back in 2001! Their SOAP stack evolved into an ESB. I'm not aware of any (major) organization in the Benelux using CapeClear.

CapeClear was also one of the 1st (from version 6.5) to have a persistent WS-ReliableMessaging implementation. So not in memory like many other WS-RM implementations, but with state and messages safely stored persistently in a database.

Idempotent services

Definition of idempotent: Refers to an operation that produces the same results no matter how many times it is performed." See also the "Idempotent receiver" pattern.

An idempotent service makes life much easier in the unreliable web services world. A service can be invoked multiple times without any side effects. This is highly useful when a service invocation times out (was the service executed yes/no). But also to re-try execution of (part of) a business process.

Making a service idempotent consists of 2 parts: duplicate detection and caching of response messages. Duplicate detection I discussed in an earlier posting. Returning of earlier response message is somewhat harder: each response message must be stored for a reasonable amount of time.

Idempotency is not mentioned in the WS-* specs nor in the WS-I basic profile. Making web services idempotent is left as an exercise to the designer/developer.

With REST, a number of verbs such as GET and DELETE are idempotent. POST (create) is obviously not idempotent. PUT (update) should be idempotent. I can believe PUT to be idempotent in a document world. But PUT is an update and therefore a change in my opinion.

As already explained in my earlier post, the ideal location to do duplicate detection and make services idempotent in the back-end services themselves. Interesting to learn about support for idempotency in recent SAP products (Netweaver 2004S SPS09 / ECC SE 600 SP03). SAP stores the response messages in a "response store".

Besides duplicate detection, let's ask ESB vendors to implement support for idempotent services through a "response store".

Duplicate detection

A basic mechanism to make a service idempotent is duplicate detection. For one-way services, duplicate detection may be sufficient, Request/response services require also that exactly the same response message is returned.

Duplicate detection isn't that hard:

1. Unique value in the request. Multiple options exist:
• business identifier such as purchase order number
• hash of the input message or
• technical identifier such as WS-Addressing MessageID
  
2. Database table with unique constraint to manage the identifiers.
3. Cleanup job to remove old entries from the above database table.

The ideal location to do duplicate detection is in the back-end services themselves. The service is invoked in a transactional context and has already access to a database. But it can also make sense to do duplicate detection in an intermediate such as an ESB. E.g. when an ESB switches between an unreliable protocol such as HTTP and a reliable persistent queuing protocol.

Integration solutions often need to maintain information about messages anyway. For
message monitoring, message archiving or non-repeduation (keep copy of signed messages). Duplicate detection can also be combined with protection against replay attacks (even required by the core WS-Security spec).

Mule comes with an Idempotent Receiver that provides duplicate detection.
Still, why other ESB's don't come with duplicate detection mechanisms is a mystery to me!

JSON

Many message formats have been defined for exchanging structured data: ASN, DCE RPC, ONC RPC, IIOP, DCOM IDL, , ... Many alphabets have been defined, on which new languages (message definitions or RPC contracts) were built!

Although XML had its roots in the document centric world (as a successor for SGML), XML gained an immense popularity in the world of structured data. XML was considered a good standard for self-describing messages: no mixed content but tree-structured messages with data only at the leafs of the tree. First DTD's and next XML schema's provided mechanisms to describe the XML messages.

Pushed by HP's eSpeak and XML-RPC, the SOAP protocol triggered the creation of the WS-* stack. But with the rise of AJAX and other Web 2.0 technologies, new alphabets emerge and gain popularity. JSON is one of those new kids on the block.

Rich Internet clients are not limited to HTML but use all sorts of message structures on top of HTTP. With the use of Javascript in the browser, a Javascript friendly protocol eases life. That's what JSON is all about. Apart from JSON, many other protocols such as Adobe AMF pop up (performance comparison, thanks Stephan for the link).

Now, what is the impact for the integration world. Of course, JSON and others will be used for a few A2A and B2B scenario's (although I haven't seen any yet). But many tools will need to extend their XML support not only to REST, but to many other protocols. Organizations will keep one main entry point for all their HTTP traffic. Next to HTML and XML, JSON and others will be added. Therefore, infrastructure will be impacted first, e.g. XML gateways will need to add JSON support change their name from XML gateway ;-)

Standard ways of using JSON are already popping up, e.g. JAX-RS (JSR-311) adopted Jettison for JSON support and includes JSON-XML converter which follows the Badgerfish approach for JSON-XML conversion.

JSON-XML deserves our attention: a widely accepted XML representation for JSON (don't use the word "standard") will allow re-use of transformation logic. But I have some doubts around this Badgerfish JSON-XML conversion. It takes XML as a starting point, e.g. it puts XML namespaces inside JSON which doesn't look nice.

Note: while attending SpringOne, I was caught by surprise when encountering the first use of JSON for a configuration file (for the new Spring container if I remember well)

Sub-mappings like sub-routines

Mappings or transformations are one of the most important parts of integration flows. A lot of energy is spent on developing, maintaining and managing such transformation logic. In an XML world, transformations are often developed using XSLT (and some XQuery). But besides these nice standards, a lot of other more proprietary transformation solutions are used.

Just like with normal application logic, integration developers will always strive to re-use already existing interfaces and message formats. E.g. a new application or business partner will be pushed to re-use an already integration flow and corresponding message layout. Existing transformations maybe extended to support specific requirements, thereby going through quite some testing.

But "re-use" of smaller pieces of transformation logic is not done. The concept of invoking lower level pieces of transformation logic does not apply. There are no libraries from which smaller pieces of transformation logic are re-used in multiple mappings.

And this is not even the case within a single mapping. E.g. for transforming a structure occurring multiple times in a source and target message (take for instance a shipping and invoice address), no subroutine (such as TransformAddress() ) will be used.

There are a couple of reasons for this way-of-working:
- messages are often not constructed from standardized building blocks
- source and target message must contain the same data structures multiple times
- re-usable pieces of transformation logic are often small
- managing the re-use of transformation logic across mappings requires discipline
- tools and standards are not helping much
Still, I find it strange that "modularization" is not applicable in the world of integration.

EAI is dead, long live EAI

Andreas Egloff from Sun Microsystems gave a talk at the JavaOne AfterGlow event on project Fuji, which is Sun's initial development for OpenESB 3.0. During his talk, he repeatedly stated that the latest communication channels such as RSS feeds are not that different from other connectivity options such as file transfer. I couldn't approve more with his "EAI is dead, long live EAI". Indeed, many of the basic principles apply. It is not about revolution but evolution.

Note: at the same event, Stijn Van den Enden gave a great talk on JSR-277 and OSGi, congratulation Stijn!

Oracle Service Bus

From the podcast Oracle Middleware Strategy Update, I learned more about what Oracle will be doing with the BEA SOA products and how they will integrate or co-exist with the Oracle SOA Suite.

Interesting to hear that AquaLogic Services Bus (ALSB) will become the 2^nd ESB of the Oracle SOA Suite, called the Oracle Service Bus. This product is positioned as a "standalone" ESB, extremely fast, light-weight and highly functional, but tied to the BEA WebLogic application server.

Oracle will drop the BEA SmartConnect adapters and retain its own JCA adapters, with exceptions being e.g. the REST adapter from BEA. Oracle also goes for its own Web Services Manager for policy based security (based on security solution obtained from Oblix). Oracle will drop the BEA security solution and stop the relationship with Amberpoint. But Oracle will retain the BEA Event Server (Complex Event Processing) and BEA Repository (Flashline acquisition) as well as AquaLogic BPM (Fuego acquisition).

Interesting to learn that Oracle retains the BPM solution to complement their (strong) BPEL offering (Collaxa acquisition). Many integration vendors have 2 process management solutions: one more low level focusing on BPEL and integratino processes and one more high-level focusing on process modelling, human interaction (workflow) and business rules.

Oracle has made more podcasts available on other related BEA products. Nice to hear such clear statements from Oracle regarding the future of some of the BEA products.

Ethernet over powerline

The house I live in has quite some steel and concrete. This causes the Wifi connection upstairs to drop often and there is also some latency. Therefore I started digging around for a solution. A good friend of mine suggested the use of Ethernet over powerline, so use the electricity circuits in your home for transporting bits and bytes at high speeds. The maximum speed is currently 200 Mbit, which results in real throughput of maximum 50 to 60 Mbit. There are 2 camps: Homeplug AV with Intellon chipset and UPA with DSS9010 chipset from DS2. My good friend strongly recommended the 2^nd option.

I bought a set of 2 powerline adapters from D-Link for 150 EUR, just plugged them in and voilà. The adapters work fine with latency below 4 ms and very stable connectivity.

For the security aware: Homeplug AV uses AES encryption and my UPA solution only uses 3DES. I don't know if and from what distance neighbors could try to break into this network connection.