As the web constantly evolves, so too do its foundations. Today, the web as we know it is built on web applications, web services, and APIs. This is a natural evolution from SOA (Service-Oriented Architecture) which was the foundation for a loosely coupled environment a decade ago. In SOA, services and contracts can be consumed across different networks within an enterprise. Now, with the consumerization of the Internet, SOA has been extended with APIs and interfaces that we all (consumers, end-users, and developers) want to interact with.

All web services and APIs require some form of security: authentication, authorization, secure communications, encryption, attack mitigation, etc. And over time, XML gateways have evolved to provide security for APIs and services in an easily scalable and efficient way.

Some of the use cases of XML and API gateways (source: Wikipedia)

  • High speed transformation and processing of XML traffic
  • Security and Governance of Service Oriented Architectures or SOA
  • Control of Web application API’s that are commonly exposed as REST interfaces
  • Integration of enterprise applications to services hosted in the cloud
  • Data routing and transformation
  • Filtering

Of course if data is sensitive, APIs and services may well need much finer-grained authorization than is available in an API gateway solution. Risk, context, content, etc., may all need to be taken into account. In order to achieve such a level of authorization it is now possible to extend XML applications with the Axiomatics Policy Server, (APS) which brings attribute based access control (ABAC) to APIs and services. Thus access to data is granted or denied based upon multiple factors, which are governed by your corporate policies and regulations.

Standards-based authorization – the XACML architecture

APS is a standards-based authorization solution that is built on top of the eXtensible Access Control Markup Language (XACML). The XACML architecture can be summarized in the following diagram. At its core, lies the policy decision point (PDP) which is responsible for processing incoming authorization requests and producing authorization decisions based on a set of pre-defined authorization policies and attributes.

Policy information points (PIP) can be used to provide the PDP with on-demand real-time attribute values in order to deliver fine-grained, dynamic access control. For instance, using a PIP, the PDP can retrieve a user’s risk score or a document’s classification from an underlying risk engine or content management system respectively.

The policy administration point (PAP) is used to author and manage authorization policies. For anybody not familiar with XACML Axiomatics has released a developer-friendly PAP which uses ALFA, a language syntactically similar to Java and C#. It enables you to quickly and easily write ABAC policies that are converted on-the-fly into XACML.

Lastly – and this is the focus of today’s blog post – the policy enforcement point is the piece of the architecture responsible for:

  1. intercepting a business request (e.g. a user web request to a backend servlet)
  2. creating an authorization request using any number of attributes available from the business request and the context
  3. sending the request to the Policy Decision Point (PDP)
  4. enforcing the decision it gets back from the PDP

XACML-arch

The PEP can take several form factors depending on the nature of the application, service, or piece of data being protected. If we are dealing with web services, then an XML or API gateway is a natural choice to act as a PEP.

Enforce Fine-grained Decisions with CA API Gateway (formerly SecureSpan Gateway from Layer 7)

To apply XACML to a wide range of services and APIs simultaneously, you can use a gateway that sits in front of and protects the services & APIs. For the purposes of this particular blog, we are using and integrating with the CA API Gateway

The API gateway allows an organization to virtualize their SOAP, REST and JSON APIs – manage versions, meter usage, restrict access by identity, rate limit based on SLAs, and aggregate or compose virtual APIs from existing interfaces.

With Axiomatics’ ABAC solution, users define the level of granularity required for authorization. The Axiomatics Policy Server makes it possible to implement secure data and information sharing in such a way that only relevant individuals can access the required set of data under the right circumstances.

Typical scenario – sharing sensitive data in the healthcare industry

To put this into practice, let’s assume a healthcare provider wants to expose APIs to its partners, patients, and customers alike to provide up-to-date information such as electronic health records (EHR). In order to securely expose the APIs, the healthcare provider decides to use the CA API Gateway.

Because of stringent regulations and compliance rules, the healthcare provider needs fine-grained access rules to be applied to any sensitive information. Some of the rules that need implementing are “care-relationship” rules such as “doctors can view the medical record of a patient they are assigned to”. Others are “break-the-glass” rules cases where, for instance, a patient becomes ill in a different location than their home region and a doctor needs access to their records. See additional examples here.

In practice

Bob, a medical practitioner, tries to access the medical record of patient Alice. Bob uses his mobile application to browse patient data, while he is at the county hospital.

The CA API Gateway intercepts the client application, validates it for various threats, validates the message format (step 1), authenticates the user (step 2), and then creates an ABAC authorization request. This is then sent to the Axiomatics Policy Server. In doing so the CA API Gateway acts as a policy enforcement point (PEP). Further details of the implementation can be found in this demo.

The authorization request is as follows:

  • Can user Bob view the medical record of patient Alice? (step 3)

The Policy Decision Point (PDP) at the heart of APS evaluates the access/authorization policies and retrieves any necessary metadata (e.g. Bob’s role, department, location as well as Alice’s family doctor, current treatment location but also contextual data such as Bob’s IP and device type) needed for the evaluation. The PDP then returns a decision (either Permit or Deny) to the CA API Gateway:

  • Yes, Bob can view Alice’s medical record

  • or No, Bob cannot view Alice’s medical record

If the PDP replies Permit in step 3, then the CA API Gateway forwards the original business request to the targeted services (step 4).

Policy flow in the CA API Gateway

The screenshot below illustrates a sample policy flow in the CA API Gateway. Using assertions available out-of-the-box, the CA API Gateway can analyze the message payload – be it JSON, XML or another format – and extract values from the messages to create an authorization request in XACML. The CA API Gateway can extract information from headers, message parts, and contextual attributes e.g. user IP or time of the day. This information can be used as attributes in the authorization request which it sends to the Axiomatics PDP.

Upon receiving the request, the Axiomatics PDP evaluates the request against the XACML authorization policies and reaches a decision, either of Permit or Deny. This decision is returned in a response message to the CA API Gateway processes the response and acts on the decision. Based on the decision, the CA API Gateway can route the message in different branches of the CA API policy and eventually route the message to the target API or return an exception or custom message e.g. Access denied.

Screenshot of the CA API Gateway Management Interface.

Conclusion

If you need to effectively protect APIs and services, using an XML appliance, such as the CA API Gateway, in conjunction with the Axiomatics Policy Server, makes for an effective solution that is fast to deploy and operate. The gateway lets you protect your APIs effectively while the policy server lets you define fine-grained authorization based on the message payload and additional contextual data.



Leave a Reply

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