Architectural Pattern for XML Gateway - Service Bus Sandwich

I was in a discussion yesterday with a customer and the question of "Do I need an internal gateway in addition to my ESB?" came up. In general, people thing about XML gateways as the security appliance that you stick in the DMZ to prevent unauthorized access to services (i.e. the Super PEP). So, why do I need another one in my internal network?

Service Bus Sandwich

I think the most basic reason is that the system that does security processing at the front of the bus should be the same system that does security processing at the back of the bus. This promotes a consistent approach - same policies, same certificates, same administrative interfaces. This also optimizes the capabilities of each component in the architecture - XML Gateway off loads the security processing from the ESB - SSL Termination, XML threat checking, authentication, authorization, message encryption/signing etc. - and the ESB does what it does best - routing, transformation, service virtualization, protocol translation etc.

So, with all of the security processing off loaded to the XML Gateway, how should the ESB and the XML Gateway work together to pass security context. I think the simplest way is to simply use 2-way SSL between the front XML Gateway and the 2-way SSL between the back XML Gateway. This ensures that the ESB is receiving valid messages from the XML Gateway and that it can continue processing the message. Likewise for the back XML Gateway - since it trusts that the request is from the ESB, it can send the message off to its next destination. This makes the sole security interface between the XML Gateways and the ESBs a common trusted Certificate Authority.

If more information needs to be passed form the XML Gateway to the ESB - like the identity of the calling service/user, then you can simply use SAML bearer profile. This profile basically means "trust this assertion if you want.". Since we know the request is over 2-way SSL, bearer seems fine. You could optionally have the XML Gateway or STS sign the assertion, but its probably not necessary. If you're inclined to add the additional control of the signed assertion, you're only adding a public key/CA to the ESB - still a pretty minimal binding.

Looking at the back XML gateway, this is basically the Cloud Service Broker - mediating out access to services in the cloud - but what if you're not using any cloud services yet. Do I still need have the 2nd XML Gateway? Besides the benefits of centralization and consistency, lets look at another real world use case. Information arriving at the front gateway was secured in transmission using 2-way SSL, but contains PII that needs to be masked from the ESB while being processed - it can't be exposed in the clear, in logs, etc. - but the target service requires that information for processing. In this case the front XML Gateway can encrypt/mask the contents of the message and the back gateway can decrypt/unmask the message prior to being sent to the back end service.

In summary, in architectures that contain an ESB, having both a front XML Gateway to secure incoming traffic and a back XML Gateway to secure the outbound traffic provides real benefit. This may or may not represent two physically separate deployments - it just depends if the out bound traffic is allowed to be sent back out through the DMZ. The trust among the components can be done via transport - typically 2-way SSL. This greatly simplifies the administration of security policies, and optimizes the utilization of both the ESB and the XML Gateway.