Dynamic Authorization to redact data in for the Apigee API Gateway

Axiomatics   ·   Monday, April 15th, 2019

Extending the authorization capabilities of an API Gateway to use fine-grained dynamic authorization with the Axiomatics Policy Server is a common use case.

There are several different aspects of authorization that are typically applied to API’s:

• Authorizing whether or not  an API can be invoked by the user or application
• Authorizing data that the API returns. There are typically two options here:
  1. Redact the actual data in the API gateway
  2. Perform the redaction of data before the API Gateway retrieves the data from its data source (i.e. a proxy between API Gateway and data source).

Authorizing an API

We usually refer to the first option above as “Authorization on the way in,”  and for the second option, as “Authorization on the way out.” Authorization on the way in has been covered in several other resources:

• How to use a JSON XACML Policy Enforcement Point to secure REST API endpoints using ALFA, XACML, and JSON
• Enhancing API Security: Dynamic Authorization to Protect Sensitive Data

At Axiomatics, we have integration guides on how to achieve fine-grained authorization for Apigee, CA API GW, Axway, Mulesoft, AWS API GW, Oracle, Azure and Kong. However integrations are not limited to only these products as in many cases the API GW has native capabilities to call the Axiomatics PDP for authorization (and in these cases it’s merely a matter of configuring the gateway).

In other cases there may have to be some code developed that can make a callout to the Axiomatics Authorization Service, and that is something the Axiomatics Customer Relations team can assist with on a needed basis.

Data masking/filtration

Authorization on the way can be handled primarily through two architectures – either using the Axiomatics Dynamic Authorization Suite, or handling the authorization directly in the gateway.

Use Axiomatics Data Access Filter (ADAF) or Axiomatics SmartGuard (SG)

This approach allows for interception of the request for data from a data source. ADAF or SG will be located between the API Gateway and the data source as a proxy and enforce policy based authorization of the data as well as policy based redaction and/or masking of the data.

In this scenario the API Gateway has no knowledge that data is being filtered or masked. The gateway is simply trying to get data like it normally would from the data source and ADAF or SG will handle the authorization of the data.

The way this is handled is no different from how ADAF and SG would normally be deployed. It is however dependent on the data being stored in data sources that ADAF or SG supports.

Redact or filer/mask data directly in the gateway

A solution that might be more flexible is to redact the data directly within the API gateway. Some gateways might even have native capabilities for this. However in almost all cases these capabilities are fairly simplistic and cannot be based on a fine-grained policy on when to perform the data redaction or masking.

There are three main technologies to use for this type of approach:

• Obligations and/or Advice
• Multi Decision Profile Request (MDP)
• Axiomatics Reverse Query

Obligations and/or advice

Obligations and/or Advice adds the capability of returning additional information together with the decision that is returned by the Policy Decision Point (PDP).

When authorization is handled on the way in to determine if the user or app is allowed to invoke the API call in the first place, the PDP can also return one or more obligations that determine what should be masked or redacted.

The below snippet of a policy represented in ALFA (learn more details on ALFA) returns an obligation called “fields.”

The obligation returns an attribute with the name mask_fields and assigns two values to that attribute, owner and status.

In this example scenario, the calling Policy Enforcement Point (PEP), in our conversation and API gateway, would get this information as part of the response from the PDP. The gateway can then parse the response and from that determine that in this given scenario, the owner and status fields of the return payload should be masked.

Multi Decision Profile Request (MDP)

A Multi Decision Profile Request, also known as an MDP, is the concept of sending multiple Permit/Deny requests in one batch to the PDP. The PDP will then process the batch of Requests individually as separate requests and then return multiple decisions back to the PEP.

This allows for the policy to be very explicit about what to Permit or Deny and policies can be expressed for each filed.

Below is an example policy expressed in ALFA that will give an explicit Deny decision for the fields owner and status of the records department is not the same as the user’s department. The PEP would ask the PDP, “Can Alice access field owner or status when performing a GET request on client record 123?”. The PEP (The API gateway) will then treat the Deny decision for those specific fields as an indication to mask/redact the fields.

For more details on the MDP please refer to the OASIS specification: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-multiple-v1-spec-cd-03-en.html

Axiomatics Reverse Query (ARQ)

Axiomatics Reverse Query is an authorization endpoint that the Axiomatics PDP exposes (if enabled) that allows for sending powerful open-ended authorization requests. Instead of asking Permit/Deny type authorization queries it is possible to ask open ended or listing type of requests. These types of requests can range from being extremely open “What can Alice do?” to “What records can Alice view in California?”.

It is also possible to ask for example action specific requests such as “Given Alice and California, what can she do with record 123?”. The result might be view, edit and delete.

It would be possible to apply this concept for masking/redaction also. The same policy as described for MDP would be possible to use and the access request would be something like “What fields for record 123 would Alice get a Deny decision for?”

ARQ would possibly simplify the request somewhat as it can as one access request for several scenarios. The response from the PDP (the ARQ endpoint) would be something that the PEP (the API gateway) have to parse. The full response from ARQ would basically contain a set of filter statements that the gateway would parse and use as input to the mechanism that performs the actual masking/filtration.

This would be an extremely powerful approach but might also require a bit more work from the perspective of handling the response.

Final Thoughts

It is important to distinguish the responsibilities in the scenario for data masking/redaction in the gateway. The PDP will determine under what circumstances data should be masked/redacted but is not responsible for actually performing the masking/redaction.

This is handled by the PEP and that is in this scenario the API gateway. This could be implemented in many different ways depending on the capabilities of the gateway.

Learn more about how Axiomatics provides authorization solutions for API gateways.