This fragment is based on the Cisco Learning Library, interactive online course materials: Introducing Cloud Consumer Security (SECICC) v1.0
Application Programming Interfaces, or API’s, provide a mechanism for machine-to-machine or application-to-application communication. Through API’s, entities can send or receive “API Calls” between each other, and the receiving entity will attempt to perform the requested action.
API’s abstract the code subroutines and procedures of the application, and present objects and actions to the API consumer. For example, a firewall API might present an ACL object to the consumer, and ACL actions of add, modify, or delete. The API consumer would push a request to the firewall API to update an ACL, and the firewall would then instantiate the ACL or modify the API’s are not mandatory – application developers are not required to write API’s, or to publish any documentation about their API’s – but API’s are becoming the de facto standard as more and more product vendors implement “open” solutions.
Manufacturers who implement API’s in their equipment typically implement Northbound API’s and Southbound API’s.Each vendor implements and secures API’s according to their own best practices, but most API calls require authentication by the user before the API will call or execute internal code. Some API’s will allow read access without authentication, some API’s will not. Some API’s allow full control without authentication. It’s important that you understand the API mechanics of your particular application when designing your network connectivity.
Many modern APIs are accessed through HTTPS, though other protocols like SCP or SSH can be used.
When applications need to use APIs to communicate directly with other applications – without any user intervention – they typically authenticate through an API Key. Some API’s offer unique API Keys for a specific authorization profile – and, some API’s allow you to create custom authorization profiles – while some API’s provide a very basic, “All-or-Nothing” API Key.
You typically will find this API Key through the API interface (displayed in the GUI or you might have to issue a “GET” command for a formatted-text interface). You then copy this API Key from the providing application to the consuming application, and the consuming application can then make API calls to the providing application.Note that these API Keys are typically good until canceled, and the API provider typically does not identify the API consumer; the API consumer is authenticated, but not identified. As long as the API consumer presents a valid API key, the API provider will typically accept the incoming request. If you decommission the consumer application, the API Key is still valid unless you explicitly revoke access for the API Key or delete the key.
Recent Comments