Management API - internal structure

[Maik]

Hello guys,

I have a question that is directed to the management API developers from Check Point here. It is regarding the general internal structure of the management api and how all components play together. So to first give a summary of what I understand; the "mgmt_cli" command as well as the RESTful API both process their requests via TCP 443. The Smart Console API field does not do this.

Small interconnectivity summary:

Client Based API (mgmt_cli commands) & RESTful API (web requests) ==via TCP 443==> Multi Portal ==> api web server ==> CPM process ==> postgres SQL database

SmartConsole API functionality ==> CPM process ==> postgres SQL database

I was already able to verify this, by executing commands via python scripts by using the python sdk that basically sends HTTP POST messages to the management server via TCP 443 (HTTPS). The same is done by using the mgmt_cli locally on the management server or from a different device (e.g. the machine that runs the SmartConsole, via the mgmt_cli.exe). This also leads to my first question; is the "mgmt_cli" command basically "translating" my cli input into web requests, the same way as the python sdk is doing it or is the mgmt_cli application using a whole different approach?

Another point is, I also verified, that the SmartConsole API functionality is not creating any HTTPS traffic, thus letting me assume that the whole API procedure is different compared to the "normal" RESTful API way that I have explained before. So... are there two different API's that basically exist to achieve the same goal, one accessed via HTTPS and the other via some inernal calls? Are there any differences when it comes to the actual features of both?

I just want to understand the whole structure as I experienced some delays by accessing the API and it would be interesting to be able to troubleshoot it & also for further usage.

Thanks in advance and regards,

Maik

[Robert_Decker]

Hi Maik,

I'll give you a short answer now, and next week at work I'll provide an architectural flowcart.

You are right in your findings about TCP 443 port, which is a default port and may be changed by the user.

All requests are directed to APACHE server, that then redirects the API requests to a Jetty application server dedicated for API (AKA API server). The APACHE server acts as a HTTP Proxy. Jetty server port is different and dynamic.

The mgmt_cli tool is a little application wrapper that translates the command line parameters into a REST POST requests using JSON payloads. It also wraps async calls like install policy command and waits until completed. Very convenient.

Our Python SDK is like mgmt_cli tool - sends REST POST requests and also wraps async calls.

SmartConsole CLI Tool uses the existing connection channel to CPM server, which is another Jetty application server behind the APACHE server. In this case, there is a special web service that redirects the API calls to the mgmt_cli tool. Therefore, in this case, there is a little overhead - mgmt_cli tool is invoked as a separate process by a web service inside CPM process.

Hope this helps,

Robert.

[Maik]

Thank you very much so far! Looking forward for the architectural flowchart

[Robert_Decker · Accepted solution]

[PhoneBoy]

Maybe Heiko Ankenbrand‌ can add this to his excellent diagram