Just saw here that CXF has graduated to an Apache top level project. I have long been a fan of CXF and Celtix before that. In my SOA, Web services security class we generally use both (and Axis2) to demonstrate concepts and build security into web services.
In terms of comparing security features in CXF and Axis2, it looks like CXF is relying on WSS4J for security services just like Axis2. WSS4J gives a nice way to program to XML Signature and XML Encryption (which is provided by xmlsec), but it looks to be implemented differently in CXF where you are coding properties for WSS4J interceptors
outProps.put(WSHandlerConstants.ACTION, "Signature"); outProps.put(WSHandlerConstants.USER, "myAlias"); outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS, ClientCallbackHandler.class.getName()); outProps.put(WSHandlerConstants.SIG_PROP_FILE, "client_sign.properties");
Whereas, Axis2 has an additional layer on top WSS4J called Rampart, Rampart has the notion of Outflow and Inflow security where Rampart handlers perform operations like Sign/Verify, Encrypt/Decrypt and so on. These are configured in XML as opposed to being coded:
<parameter name="InflowSecurity"> <action> <items>Timestamp Signature Encrypt</items>
The other thing that Rampart is the ability to hook into WS-SecurityPolicy as the great security architect Bill Gates says: "security should depend on policy not topology.", and WS-Trust so now you can build out an Security Token Server (STS) in Rampart. How you can sell/buy/run an ESB with out a STS is a continuing mystery to me - yes ESB vendors that is directed at you.
Anyhow, it looks to me that the Apache community has now produced not one but two ESBs that have potentially far more advanced security functionality than what is generally available in the ESB product categories.
By way of contrast - until the day I die, I will never understand this statement from our friends at IBM regarding ESB security:
“From the product design point of view, WebSphere Message Broker as an ESB is not the right place to implement WS-Security functionality. However, WebSphere Message Broker definitely is able to deliver the SOAP message with security credentials to its destination”
Great. We can deliver the message. We don't know who sent it, we cannot tell you if its been tampered with, but we won't lose it. What's interesting of course is that IBM sells another ESB Datapower that like its XML Security Gateway compadres is perfectly capable of
1. Delivering the message
2. Performing basic security services like authN, authZ, and so on
You can certainly complement WMB with Datapower or other XML Secrity Gateway and I know that is something that IBM pitches in its designs, but there is a big difference between realizing you have to complement and saying its not the right place at all. The graphic below shows possible options of implementing security in an ESB.
Of course there is a fourth approach which is you have security on the ESB and a XSG adapter, and this is often the best approach. I will have more to say on ESB security shortly, but in the meantime, should we really be worried about delivering things that we cannot verify? It seems to me that this approach leads to a highly reliable Sgt Schultz-style "I know nothing, I see nothing" implementation.
In the meantime, big ups to the Apache community for putting some hooks into interesting security primitives that facilitate building out much more advanced security architectures.