Proxy HTTPS implementation using Red Hat Fuse

Security is one of the primary factors to be concerned whenever an API is being exposed. Proper security in place means , prevention of data being hacked or modified and always an encryption link is in place between client & server

Very recently one of our client came up with a requirement to expose API using both HTTP and HTTPS protocol for all Services in ESB layer. Applications within the premise using HTTP and Applications out of the premise using HTTPS. We looked for an alternative requirement to use servers like nginx , API Gateway Management etc… , but the client is out of budget to implement any new product. So this has to be done within the there purchased licensed product. Parallely , the number of services ( Currently : 30 ) increasing rapidly day by day with new requirements coming up on each day. Few of the services are already in production and remaining about to go very soon.

Code Change in this situation is a highly risky task , so without touching the existing code we need to do something in this situation.

That  Eureka Moment

Yes, we decided to create a Proxy layer before ESB, The creation of a layer is done in Fuse itself.

How we implemented ?

What are the advantages of this layer in ESB?  

So going forward this blog tends to provide a solution for that

BefBefore going there let us see how the current architecture was, Middleware receiving JSON request via HTTP Protocol and the response is also in JSON via HTTP Protocol with no security layer.

How We implemented  ?

We created a proxy project in Fuse itself, which receives the request via HTTPS Protocol and with the help of cache mechanism logic which we redirected the received request to the specific URL in the ESB layer via HTTP

At The ESB Layer API’s like Create Customer, Create Loan being exposed via HTTP Protocol. Certain Client Applications ( Like Client A in the Diagram ) are present in the premise, while few are outside the premise zone( Like Client B in the Diagram ). For Clients outside the zone, the existing services must be exposed through HTTPS. To achieve that in Fuse we exposed API using restlet component with HTTPS and SSL context layer mentioned in the bean class.

As you can see the New Architecture Diagram, The respective URL being received in the request will invoke the cache mechanism by providing URL received in input as key, the output from cache will be HTTP protocol URL which is already being exposed at the ESB layer. The response from the ESB will be sent back to the Proxy layer, which in turn sends back to Client Applications.

Adavantages of this implementation :

1. No need for additional products to implement the security layer.
2. Both HTTP and HTTPS protocols are being in place.
3. Easy to add new API in DB straight away without any coding
4. Load Balancer can be done for JMS receiver Applications.
5. Easy to maintain.

Caution :  When you try to expose all the API’s using Proxy layer you must keep in mind of Number of requests being received for all applications. If you feel request receivable is heavy from client applications, the best way to do is clone the project and implement it , with only change in IP or port .

You can clone as many times you feel want , per client per  proxy project would be ideal if the client invokes too many requests.