A Beginner’s Guide to Layer7 API Gateway Policy Writing

Article By: Eunice Mushawatu

Your organization has acquired the Layer7 API gateway, and you are ready to take advantage of its capabilities to improve your API management and protect your APIs. Below, we’ve put together a comprehensive guide to layer7 API gateway policy writing for the complete beginner, which walks through the basic concepts of the Layer7 API gateway policy logic and how to protect a basic endpoint.

Understanding Policy Logic

Policy logic is the method or language by which the policy manager creates complex services. The policy manager has an assertions palette, and assertions are the building blocks of a policy. Think of an assertion as a single purpose function represented in a single line. The gateway uses a top-down approach reading these assertions. Each assertion returns Boolean “true/false” values, that combined with composite assertions—assertions that give the ability to group relevant assertions together— is what allows for the expression of powerful decisions in policy.

Composite Assertions

Composite Assertions give the folder structure to the policy and reinforce parent/child relationships. The two main composite assertions are:

All Assertions Must Evaluate to True Assertion: All child assertions must resolve to ‘true’ for this assertion to be successful. This assertion functions similarly to logical ‘AND’. The gateway traverses from the top and immediately stops processing and returns false as soon as a child assertion returns false. That means that the gateway never looks at the subsequent assertions.

At Least One Assertion Must Evaluate to True Assertion: Only one child assertion needs to be true for this assertion to be successful. This assertion functions similarly to logical ‘OR’. The gateway will always go to the next assertion if they return false until it reaches an assertion that returns true.

Quick Assertions

Quick assertions either simply check for the presence of certain data or perform a simple task. Examples include all the assertions that start with ‘require’, such as ‘Require Timestamp’ or ‘Require SSL’.

Assertion Placement

Assertion placement is a large part of the policy logic. The assertion placement is how you build powerful decisions such as if-then or if-then-else structures. When using them, at least one assertion must evaluate to true composite assertion, and the placements of the child assertions will determine how long it takes the gateway to reach an assertion that evaluates to true. Think of this in terms of a sequential search—you want to arrange the options in order of decreasing probability.

Use Case

As the policy administrator, you have been requested to write a policy to protect the REST endpoint. The bulk of the users will authenticate against the internal identity provider, but only a couple users will have to authenticate against SiteMinder, since they cannot be provisioned to the internal identity provider. All APIs should be accessed over SSL per company policy. The request for this endpoint is not expected to ever exceed 120kBytes, and you have been given an IP range from which requests will be accepted.

Sample Policy

In the API gateway, there is an implied line 1: All assertions must evaluate to true assertion; that is why all policies start at line 2 when assertion numbers are enabled.

In this sample policy, we use the ‘at least one assertion must evaluate to true’ to establish the OR function. Notice the folder structure that groups assertions together, and the use of the ‘all assertions must evaluate to true’ to establish the AND function. We have two options for authentication, and each option has assertions that should all evaluate to true for the option to be valid. [Link-See article for Siteminder Authentication in Layer7 API gateway]

Notice the order of assertions; the policy checks for the validity of the request before going through the trouble of authenticating the requestor. If for whatever reason the request exceeds 120kbytes, the request is rejected earlier on.

If we expect most requestors to authenticate against the internal identity provider, it’s better to have it as option one, so that the gateway does not have to process more policy to disambiguate a user and authenticate them. The last assertion routes the request to the endpoint, and reaching the route assertion means that the user has been authenticated and/or authorized to use the protected service.

Summary of Layer7 API Gateway Policy Writing

Typically, APIs exposed to the public will have more threat protection included in the policy and many APIs require additional logic at the gateway level. This example use-case and sample policy simply show how to protect an endpoint at a basic level—request validation, threat protection, authentication, authorization, and then access.

Looking for additional help with Layer7 API Gateway policy writing? ISX Consulting is an elite IAM security firm that offers boundless expertise in a range of cybersecurity and business process services, including API integration and management. Take your interoperability to the next level, and contact an ISX consultant today.

ISXA Beginner’s Guide to Layer7 API Gateway Policy Writing

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *