Web service security – when and where

It’s always challenging to explain when, where, and how to apply functionality when there are multiple solutions in an environment that overlap. “Product A already does that, so why do I need Product B?” Occasionally a vendor will make it simpler by deprecating a function in one product when it becomes available in another (or, like CA, you keep five products that all do the same thing). Of course, this can upset users of the first product who upgrade and suddenly find they can’t do something they used to be able to. Believe me, I get it.

The old Oblix product used to do some basic provisioning and workflow, but a while after it was acquired and became the Oracle Access Manager, its provisioning abilities were subsumed by Oracle Identity Manager. It simplified the story, that’s for sure.

The old gateway functionality of OWSM (Oracle Web Services Manager) was moved into OAG (Oracle API Gateway) because, honestly, it makes more sense there. There is still overlap between the products, but here’s the deal. Whenever there turns out to be more than one way to do something, and the customer asks me, “Well, how should  I do this?” the answer could be, “It depends.” And what it depends on is:

1)      At what point in the process do you want to do it

2)      What other functionality has to surround it

3)      Who in the organization will own it

With web services security, you might qualify this with: will the security portion be owned by the SOA guys, or the security guys?

OWSM is still the way to go for last mile security. It’s all the way in the back of your reference architecture, right? It’s waaaaaay back there where your services live. The Gateway, on the other hand, sits in front of everything. Before a request makes it anywhere past the DMZ, it’s intercepted by the Gateway, validated for safety and cleanliness, protocol-transformed as necessary, redacted and/or enriched, given a thorough spanking, then sent on its way.

(In fact, the request could be throttled, measured, routed, or suffer any number of other indignities as well.)

 This IS the most secure way to do things, of course, because this means the request is vetted before it makes it anywhere toward the back, where it gets processed. Bad, evil, corrupt, malicious, or malformed requests never get the chance to eat up any CPU, since they are stopped at the front door. This architecture greatly reduces the chances of anything bad slipping through. Additional policies being handled by OWSM, or the Enterprise Manager, have their turn to take a swing if the request makes it that far. Defense in depth, right?

 And HERE is why you want to do those transformations in the front as well. Keep those decisions off the bus, out of the code, away from the apps themselves. If you’re running in SOAP, but now you’ve moved into the REST or JSON era, let the Gateway handle that nonsense, so you can take your time migrating your code or backend policies. You are future-proofing, or at least temporarily preserving, your apps or services.

Just as there is value in abstracting identity consolidation at the directory level rather than the code, there is value performing these service security and transformation functions in front rather than the back. Think of the Gateway as a security abstraction layer. By the time the service or app receives a request, that request has been hammered into an acceptable shape.

It works like this for me at home. Before we ever make it to a funeral, my wife and kids have decided that whatever I’m wearing is not going to work, and I’m wearing something completely different by the time I make it to the car.