In an API economy, content-based access control (CBAC) grants or denies a customers request based on the content that is sent. In most cases content-based access control is used along with identity processing, but it can be used on it’s own for granting or denying API requests by identifying threats, verifying signatures or validating structure of the content and messages being sent.
To implement CBAC, one of the first things that needs to be accepted is that within an API economy, cloud, mobile or B2B connections, each use different formats to send messages such as XML, JSON, SOAP, and HTML. Any content-based access control solution must be capable of inspecting content across any of these message formats. Once this is established then you can set a content-based access policy to inspected through the following areas:
Threat Detection: Perform deep content inspection to check for malware destined for the target application. One common attack where a CBAC policy can be effective is the XML External Entity (XEE) attack, where an off-the-shelf XML parser is poorly configured to allow XML that contains references to external entities. Detecting an XEE is critical for preventing corporate data breaches.
Signature Verification: The message here is inspected to see that it has not been tampered with or changed. Signature verification establishes the integrity of the messages.
Schema Validation: Depending on the message format, a schema (XSD) may be available to check the structure of a message. In cases where schemas are not available, being able to define acceptable message structures and data types is recommended to ensure that the content is fully aligned with expected business semantics.
As part of an overall access control policy, and by setting the gateway in front of the application servers and allowing content-based access control, you can protect applications and application servers.
To see a demo of how this can be done in Forum Sentry click the link below: