CA API Gateway - A bit of good, the bad and the very ugly

Quarter 1 of 2018 ...

I just recently completed the rollout of the famous Layer 7 CA API Gateway.

For the one about to make the decision of an API Gateway or API Management solution, let's share the good, the bad and the very ugly of this solution.

The use case drives the selection of the product and implementor, and there is no perfect solution, simply a good or great fit.

Engaging this well established software company and a reference product in the industry, many bad surprises came during the project.

This list shall serve more as a warning and check boxes during an evaluation process.

At the end, the CA API Gateway is meant to be used as a secured reverse-proxy that simply controls the security. Do not try to do more or brain death could be near!

The Good

  • Simple things are done super fast, in particular to do security related items such as encryption, JWT generation / validation
  • In minutes it is possible to deploy a new policy with simple to advanced security

The Bad

  • The CA consultants that joined the project were very blank on API policy design and best practice in my vertical market. And the tech presales did crap architecture that needed full rearchitecturing after project start. Anything new out there?!!!!
  • Logic flow is rather complex. The so common if-then-else logic is replaced by an obscure sequential grouping of steps under an "all success" and "only one is success" umbrella. This is annoying to say the least, and counter intuitive when it comes to AND-OR or exception catching
  • OAuth engine is there, but actually it offers only basic features. Any additional feature requires modifying the logic of OAuth engine, which increases the security risk due to a possible coding mistake

The Very Ugly

  • The gateway features are XML centric, this is clear. Has CA heard about JSON? Yes, there are couple assertions that support it. If you need more, wait and see...
  • No scripting engine at all. Well ; one way to look at it is that it prevents writing unsecure code... May be... So it means any logic has to be written using the wired tool set and flow control. In summary: horrible!
  • CA has just release a major rearchitecture of its API Portal. API Portal 3.x and 4.x are actually totally different products in their core architecture and the way they are meant to be used. The way to design API policies are quite different: the old way is API IDE to Portal publish. While the new easier, faster and more secure way is about creating API policy blocks and compose them in the Portal. Within CA and external consultants, most "experts" do not know this yet

 

Please feedback your own views and experience. I am just one (disapointed) customer out there, I am sure others are happy, and I will update the points above.

Good luck!