Continuing my adventure with Apache Rampart from my earlier article I decided to follow the DeveloperWorks article on WS-Security. Again I ran in to some issues when I tried using signatures within the messages. Here is a brief account of what happened this time.
First road block I encountered was the error shown below. The error was on the client side and was like this.
org.apache.axis2.AxisFault: CryptoFactory: Cannot load properties:crypto.properties
Client didn’t seem to know where to pick up the properties file describing trust store details. After fiddling with the file paths and failing, I tried the Axis2 list and luckily found a suggestion which helped out with my predicament. The solution was to add the properties file location to the client’s classpath. So with that obstacle out of the way the next break point to hit was this.
[ERROR] The [action] cannot be processed at the receiver.
org.apache.axis2.AxisFault: The [action] cannot be processed at the receiver.
This time around it was the server side which was giving me troubles. After scavenging a little on the Internet for information I found this article which described the issue as not properly setting the SOAP action when setting up the client. I was guilty as charged. I had forgotten to set the SOAP action at my client. Thanks to that tip I pressed ahead again to come up with this.
org.apache.axis2.AxisFault: WSHandler: Signature: error during message processingorg.apache.ws.security.WSSecurityException: An unsupported token was provided (Problem with SKI information: Support for RSA key only)
Again luckily I found a suggestion on Axis2 list which helped me through. The error was due to the choice of the algorithm that I used generate the key store. Instead of the default DSA using RSA algorithm was the solution.
So after another bumpy ride I was finally able to get it working for signatures and luckily providing encryption capability was pretty much a smooth ride afterwards.
Read Full Post »
Posted in SOA, tagged SOA on September 17, 2009|
Leave a Comment »
Today I attended the SOA workshop conducted by WSO2 Inc. with colloboration with ICTA SriLanka and SLASSCOM. Sessions were conducted by engineers from WSO2. The workshop sessions were at an introductory level of major SOA concepts. Below are some of the notes I took down during the course of the sessions.
Why just using https may not be enough for securing web services?
- Https security is present only inside the transport channel. It’s more or like point to point security. Imagine your service container app is deployed within a Tomcat instance running in your local machine. All the encryption security is present until the message comes to Tomcat. Then the message decrypted and transfered in plaintext to the service container application and subsequently to the service instance itself. What if some one within the organisation having access to the deployment server devise a method to capture the plaintext message in transit to the service from application server? Though bit contrived this may be a possiblity and where message security is of utmost importance we may not be able to get away with just using https to secure our services.
- What if we want to encrypt just a part of the message? What if the business requirement specified that a certain part should be visible to every party involved and only a certain part is subject to authorized access. This cannot be clearly achieved using https since all of the message is encrypted as it is sent over the wire.
- Soap messages can be sent using different transport applications or protocols like HTTP, SMTP, etc., which might have a very high security model to no security model at all. Hence, there is a need for a comprehensive security framework for Web services applications, which is common to all types of transport protocols.
What is then the SOA approach to security?
The SOA approach is to use XML Encryption to encrypt the message itself. This ensures data integrity of the message (ensure that the message has not been tampered while in transit) and non repudiation (making claims refuting sent messages impossible). WS-Security specifies the related concepts for SOAP related communications. UsernameTokens are used for user authentication. This typically requires username, password in clear text, created date of message and a nonce to be included in the message where it can after be secured using message or transport level security. This requires the user store information be present within the server to authenticate users. This works fine until our users are within our domain. What if we want to authenticate users from an external domain? Then we would require user store information of that external domain which is not a practical solution to the issue. This where authentication delegation comes in. Basically we don’t have to trust users. We trust a set of external security token services which ensures the users are what they claim to be. WS-Trust specification specifies how communications between the related parties should happen in these scenarios. There is one piece of the puzzle still missing. How can we communicate our security requirements to other parties. WS-Security Policy provides for this requirement.
ESB and SOA
Service bus all about connecting things. The main idea is to be able to plug in a service and make it work with minimum configurations.
Key ideas behind using an ESB
– Make service accessible independant of the transport level protocols used to access them.
– Monitoring and managing service with minimal configurations
– Transforming and mediating messages.
– Facilitating implementation of service governance
ESB SOA patterns
Federated ESB Pattern
ESB Anti Patterns
Anti Pattern 1
* Implementing all the business logic in the ESB
* Why not
– Mixing infrastructure logic and business loigc
– Maintainability issues
Anti Pattern 2
* Apply waterfall and application deployment approach to ESB
* Why not?
– Lose the flexibility and agile development requirements of ESB
ESB and Governance
Governance ensures standards around enterprise IT. It includes poilicies, processes and people interactions. ESBs can be very important for governance models. It can act as an central policy enforcement point.
Read Full Post »