CA API Gateway

 policies provide APIs to client systems, while in turn utilizing back-end APIs. Enterprise needs governance similar to that used in software deployment to govern policy deployment.

Policies can dramatically alter the structure of API calls, so they must be deployed with care and rigor. Implement a "Policy Development Life Cycle" similar to standard software development life cycles.

Fully planning a service or API deployment is not always practical as changes are invariably required. The revision control feature in the Gateway can help you manage such changes, but it is limited to a single environment.

The Policy Revision feature lets policy authors view and edit versions, or set a previously edited policy as the active version. For details on using this feature, see Policy Revisions.

  

To minimize policy changes, structure your policies to allow environmental dependencies to change without needing to update the policy (or create a new revision). The topic Gateway Environment and Configuration discusses how to use cluster properties to gain a more efficient workflow.

Modular policies are known as 

policy fragments

 or 

encapsulated assertions

. They are similar to the 

#include

 command in the C programming language: the fragment becomes part of the policy and executes using the same rules as the parent policy.

Modular policies allow subject matter experts and specialists to work on individual functions independently. This is similar to the standard practice of dividing large development projects into subsystems and assigning different teams to each subsystem.

For example, most organizations create a common "Authorization and Authentication" module as a policy fragment. Coupled with the built-in role-based access control, this can reduce errors dramatically: simply grant policy authors read-only access while allowing your security team read-write access. This prevents inadvertent changes by inexperienced staff.

For more information, see the following topics:

When policies move from a development to a test environment, most IT operations groups have different servers for various functions. This means different host names or IP addresses. You can map these dependencies to reduce effort and minimize errors.

For more information, see Gateway Environment and Configuration.

The policy language uses high level objects that operate on actions. These actions are known as 

assertions

. This originated from the WS-Policy working group, where the Assertion concept was central.

For more information, see Policy Assertions and its subtopics.

There is a long list of types of data handled by the Gateway: Messages, Strings, Numbers, Certificates are some examples. Each assertion in the policy acts on objects based on configuration and some use configuration from environment dependencies.

Actions based on configuration might be a regular expression configured entirely by the text in the dialog. An example of actions based on configuration might be how the Authenticate Against Identity Provider Assertion the configured LDAP server to verify the supplied credentials.

The Gateway policy language has access to hundreds of predefined context variables, which make data available in manageable units. For example, there are many variables available that return information about the target message. A great deal of interaction with the common assertions is via the default data that are always present during policy operation. You can refer to attributes of that data item via a variable reference such as 

${request.tcp.remoteip}

.

In addition to the large library of predefined variables, policies can create new variables during policy execution. Many assertions automatically create their own context variables. For example, any of the XPath assertion (example: Evaluate Request XPath Assertion) saves comprehensive data about the XPath in a series of context variables.

The 'Message' variable type is particularly complex. This variable type embodies the Gateway's ability to:

For information about specific context variables created by assertions, refer to the topic for each assertion. For example, the Evaluate Request XPath Assertion topic lists the six 

requestXpath.*

 variables created by the assertion.

Assertions act on the policy data mentioned previously. An assertion might change the request as configured in that specific policy. For example, the Apply XSL Transformation Assertion could modify the request message according to the specific configuration in that specific policy.

All assertions return 'true' or 'false', indicating success or failure. The policy logic you implement will branch based on these results.