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.