Architectural Patterns for XML Gateways

What a week! I didn't get stuck anywhere - except for snowed in at home - but it was really busy. I did have the pleasure of ending the week briefing a group of really smart architects and pre-sales people on the Vordel Gateway.

When talking about the gateway, it is easy to get into the weeds of does it support this crypto accelerator or this version of the WS-SecureConversation spec, or this version of some 3rd party I&AM product. For this particular audience I was trying to get to the essence of how customers deploy this technology. Here's my architectural taxonomy for XML Gateways.

• Super PEP - The super/uber policy enforcement point. This is the way that XML Gateways are traditionally deployed. The idea here is that it can enforce any type of policy you can image - WS-Security, Authorization (XACML), SLA Policy, Routing Policy, XML Threat Policy... This is of course a very solid model for the gateway, and the way that most people think of it.
• Security Services Platform - There has been a lot of talk about reusable security services for a long time. It was how we originally sold WLES/ALES/OES. The Oracle Platform Security Services - OPSS - has picked up some of that same flavor - and the concept is a good one. Let's have a set of security services that can be called from a central location. There are standard interfaces like SAML, XACML, WS-Trust, SPML etc, but how do you actually go build that into an enterprise? XML Gateway to the rescue. I think of this model as turning the gateway on its "side". Basically, the gateway has the ability to expose these WSDLs, and it has integration with all of these 3rd party I+AM vendors like Oracle/Sun, CA, Tivoli, RSA - as well as various LDAPs - that constructing these services is very straight forward. The gateway today has the ability to be an WS-Trust end-point, CRL endpoint as well as exposing an XML Encryption/Decryption and XML Signing/Validation service. Its a simple exercise to extend this model to any API - standard or otherwise. Furthermore, since the Vordel XML Gateway has very fast XML and crypto processing, the services will perform and scale.
• Cloud Service Broker - This is like you take the XML Gateway and flip it around. Mark O'Neill talked about this convergence between XML Gateways and Cloud Services on his blog. I like the architectural symmetry. By flipping it over, you mediate access to services in the cloud. The Vordel XML Gateway is really good at protecting things like API keys - to avoid the issue of having everyone in the enterprise have unfettered access to the company's storage cloud. The distributed caching capabilities of the Gateway can help in cloud scenarios in two way. First of all, caching boosts performance - no need to go to the cloud to get that file, if the gateway has a recent cached copy. The second is that it can save firms money by optimizing calls to cloud services. In the storage example, this eliminates unnecessary GETs. In a transactional example, some provides give better rates for bulk operations, so the requests can be queued in the cache, and then sent en masse, again saving money.

These three architectures provide a simple way of summarizing the capabilities of the Vordel XML Gateway. Like any pattern, they can be used in conjunction with each other. For example, you could put the Super PEP in-front of the Security Services Platform or have the Security Services Platform call the Cloud Service Broker (off site authentication via cloud). As I continue to work with customers, and learn more about how they are using the gateway, I'll be sharing more of these patterns.

How to Securely Integrate Web Services in an Enterprise Environment

I spent the bulk of today updating the technical sales presentations for some upcoming training that we're giving in Boston. While brainstorming about the key messages to deliver to customers, I came across this cartoon.



It's admittedly a little silly, but I really like the core concept of the story. The idea is that the quality of the XML Gateway solution is not strictly about speeds and feeds, but the ability of the product to work across teams to deliver real value. This is not some slight of hand - look over here at this other stuff - the performance of the Vordel Gateway is "unbelievably good" - but simply an observation about the challenges that customers face in deploying a solution like this. I drew inspiration from this presentation, so if and when you see the technical presentation, you may recognize some of the themes. As for the presentation in its raw form, I think its more "appropriate" as a web video. Enjoy!

How to Integrate Web SSO with REST web-services using Oracle Access Manager

Nothing inspires me to blog like being stuck in an airport. I'm stuck in DC on a return from my first Vordel customer trip. We saw customers in San Diego, Los Angeles, Bay Area, and Seattle. Some of them there were very interested in the integration between Oracle Access Manager and Vordel. Once again, Mark O'Neill, CTO of Vordel to the rescue.

The video demonstrates a few on the interesting scenarios combining a Web Access Management product with an XML gateway

• Authentication - By simply selecting Oracle Access Manager as a repository, usernames and passwords are authenticated against OAM - encapsulating the directory specifics and optimizing connections
• Identity Propagation - Once authenticated, the OBSSO cookie is available to down stream applications
• Single Sign On - By adding another filter - Validate Oracle Access Manager Token - the token is validated by the ASDK and the identity available to the service.

The thing that impresses me about this demo is how easy it is to do. I'm still a relatively new to the Vordel product, but the UI metaphor on building the policies using filters and wiring them together is really simple and easy to grasp. Also, the way that you can pull the output of one filter into the input of another is really useful. The UI will also mark filters as RED is you're missing an upstream input.

Having seen experts like Mark and some of the long time Solutions Architects work with the product, you can get very productive with the tool and build super complicated security scenarios with amazing ease. The biggest challenge is that the 6.0 product ships with over 140 filters. This is not a bad thing...it means that the product provides tremendous value out of the box....its not just a framework. But as some one trying to come up to speed, you realize that there is a 99% chance that there is a filter (or set of filters) that will allow you to do the job.

The other really amazing thing about the filters, is that when you're trying to debug a policy, you can use the real-time monitoring, and see the success/failures of each of the individual filters. This is super useful in diagnosing problems in any environment.

Well, they're calling my flight. Wish me luck getting home. Time stuck on the tarmac is just more time to get up to speed on the product :)

How to Enforce Fine Grained Authorization to REST Services with Vordel and Oracle Entitlements Server

Hello from Dublin,

I'm nearly at the end of a very long week for Vordel Company kick-off, but I wanted to take the time get the new blog headed in the right direction. I know that my blogging activity tailed off over the last few months, but one of my 2011 New Year's resolutions is to blog once a week - and lose 15 lbs.

Not surprisingly, my first post of the new year is on Vordel's integration with Oracle Entitlements Server. Mark O'Neill, the Vordel CTO, has posted a video demo of the integration. It follows the same basic use case as the Oracle Entitlements Server-Oracle Web Services Manager integration that I did last year, except through the magic of the gateway, its protecting a REST service.

A little background on this integration. This was an integration that the A-Team helped Vordel with a while back. What's really nice about it is that it uses the Java SM. This means that all of the calls are made inside of the Gateway. So if we take the real world scenario described in the demo of the trader making a call to get a price, then performance is super critical. A more naive approach would be to call out using XACML. The problem here is that the additional over head of creating an XML request, sending in, parsing in inside of the WS-SM, packing up the response, sending it back, and parsing again is > 100 ms. Did you even know a trader that could wait 100 ms? Also there is the additional operational complexity of having to stand up two instance of the WS-SM so that there is no single point of failure.

Ultimately, I think the best solution would be OpenAz...then you get a standard and likely an in-process implementation. Now, if you have a XACML endpoint and want to call out - Vordel does this OOTB. If you want this approach, my recommendation would be to run the XACML PDP from Oracle or other XACML vendors co-located on the Gateway (you can run the gateway as a software appliance), and then leverage the XML processing power of Vordel.

The point here is that the quality of the integration and the quality of the platform does matter. A good tight integration, like the one between Oracle Entitlements Server and Vordel has real benefits (lower latency, operational efficiency) to customers.