I would like to share some points from a recent conversation about requirements in a distributed ESB platform.This post is not going to talk about WS-Security or LDAP or encryption or any specific technology. Instead it is going to cover some of the different and maybe unexpected ways that security concerns are applied in the ESB/SOA space.
The conversation was centered on ESBs, security, and SOA. The architects I was talking to have been looking at the ESB space for around 18 months and have been using Service Mix as a prototype platform thus far. They are considering moving to Open ESB which is what sparked the conversation in the first place.
As with a lot of large organizations I have been talking to lately, they have a preference for either open source or commercial open source as well as standards based software. Their preference is driven by a desire to avoid vendor lock in and to mitigate risk if a vendor or product line ceases to be available. The standards requirement is motivated by a desire to achieve the greatest level of interoperability and portability (and all of the other -ilities that "come" with standards).
They look at the ESB as a facilitator/processor for two types of messages: data at rest and data in flight. Data at rest is any data that is persisted in a permanent storage facility (i.e. database) while data in flight includes real time data feeds and data from semi persistent sources like JMS queues. The data comes in all types of formats. Some are XML based. Some are binary, proprietary, text, etc. They also have a large interest in data streaming and processing real-time data feeds (similar to stock ticker) where there is a continuous open connection to the bus and data continuously streams through the pipe. There is no ack protocol and they want to insure that no data is ever lost.
Censorship
Because the data being processed has different levels of sensitivity, there is a need to be able to perform censorship on any message leaving the bus. The bus itself is considered a trusted zone (within it's own security domain). But any external communication must be filtered based on the authorization of the requester - or sometimes the destination. For example, it may be necessary to filter Social Security numbers out of a message that leaves the corporate boundaries. Fields or entire sections of a message may need to be removed or masked in order to insure the recipient all of the data they are entitled to but none that is restricted from them.
Identity Propagation
Service requests made from the local ESB node to any remote nodes (like for an invoke in a BP) must sometimes preserve the identity of the original requester and sometimes make the request under the authority of the ESB itself (using a certificate-based identity assigned to the ESB or the particular service itself). There is no requirement to propagate the actual user credentials, just a validated distinct name. Once a user has been authenticated, there is no requirement for re-authentication. Authorization, however is dynamic. Each access to a secure resource requires the resource to check the authorization of the authenticated user.
Secure Deployment
There is also a requirement for secure distribution of binaries. When there is a new service or a new version of a service that has been approved for use within the distributed ESB, it is distributed and deployed by a central authority. Not only does the binary need to be transported and deployed on remote ESB nodes, but there must be a guaranty that the bits that arrive at the remote ESB node are the same bits that were sent.
In other words, they need a secure deployment service that would allow complete remote deployment with no configuration to be done on the target ESB node. The intention is to minimize staff at the remote sites and relieve the local admins from the need to maintain or administer the ESB.
