fb
API Management 5 min

API Policies – PAP, PDP, PEP and PIP. Oh my!

Hans Bot
Hans Bot
Senior Solution Architect
API policies can be confusing
Scroll

API policies can be confusing.jpgWSO2 API Manager can be confusing. In fact, it is a big product, reusing features of many other products – such as the Enterprise Service Bus, the Complex Event Processor, the Message Broker, the Enterprise Store, and Data Analytics Server (which in itself is a collection of products). It covers a lot of ground – such as lifecycle management, policy management, developer engagement and policy enforcement. And all in a single product. No wonder architects and administrators are having a hard time to get their heads around it. In this post, we will try to make sense of it all.

Policy 101

Let’s start with your end-goal. You want to enforce your policies. No matter if they handle about access to your data, about rates at which your APIs may be invoked, or about authentication, without proper enforcement, your policies are fundamentally flawed. If you want to make life easy, you create a single point of access where you can enforce your policies. This is your Policy Enforcement Point, aka PEP. Having more entries is definitely possible, but bear in mind that your not in good position if you strongly secure your front door, while leaving your backdoor wide open. You can think of your policy enforcement point as the barrier at the border gate.

Having your policies enforced begs the question how to establish compliance. Again, at the border you need a legal permit. It is perhaps not that difficult to establish whether or not a person has a permit. But is it legal or fake? Is it still valid, or perhaps revoked? Is the person really the owner of his permit? Is he perhaps listed? There can be all kinds of complications involved in deciding whether or not your policy – possession of a legal permit – is violated. That is where a Policy Decision Point (PDP) comes in.

Of course, policy decisions must be fair and as objective as possible. You do not want each of your customs officer to make up his own rules. To unequivocally define your policies, you want a Policy Administration Point (PAP). This is the source where your PDP will rely on. Notice that policy administration and policy enforcement are different trades. It may take months to develop and test a policy, or a policy change. And you typically release policy updates once a week or once a month. Policy enforcement, however, is a 24×7 operation, where decisions must be swift and waiting times must be avoided.

To bridge the worlds of Policy Operations and Policy Development, you probably want to create situational awareness. How are your policies working out? Any need to fine-tune them? Or perhaps you want to simulate and assess the impact of planned policy changes? For that, and many other things, you will need information on your operation. Please meet your Policy Information Point (PIP). That’s where you can monitor all the decisions taken, and assess if your policies work as designed. In fact, that’s how you close your policy loop.

attachment 1 - API policies.png

API Policies

So, how does this map to WSO2 API Manager. Well, you won’t be surprised to learn that the API Gateway is, in fact, your PEP. It is the point of access that either allows entrance or not. This Gateway comes with a pair of assistants to help decide on its policy enforcement: the Key Manager – which is tasked to decide on your access control policies – and the Traffic Manager – to operationalize your throttling policies. These are your PDPs. The way WSO2 has implemented the interfaces to these components is a bit different. The Key Manager interface is a real-time interface, with an optional cache to optimize the overall performance. The Traffic Manager, on the other hand, has a near-real time interface. It gets continuously fed with events, and continuously monitors API traffic and evaluates if policies are violated – which may involve complex queries in large sets of events. When a violation does occur, that implies the Gateway must as soon as possible update its operational ruleset – the set of simple rules it evaluates real-time – e.g. an IP blacklist. So the Traffic Manager sends a message to the Gateway to do just that. You can think of it that in a way the Traffic Manager delegates real-time decisioning to the Gateway with this simple ruleset, much in the way the police shares a list of stolen passport numbers with customs.

The API Publishing and Management Portal is obviously a PAP. It’s where your define your API-policies, after all. And to a certain extend, the API Developer Portal is also a PAP – that’s where a developer defines valid application and manages his subscriptions. Depending on the workflows you define, different roles may be involved in deciding which developer registrations and what API subscriptions to accept. Effectively, your workflows are a PDP too.

API Manager Analytics serves as the PIP in WSO2 API Manager. Here you can delve into all the reports API Manager generates out-of-the-box. And if you want more than that, there’s always the option to upgrade to a full WSO2 Data Analytics Server.

attachment 2 - API policies.png

Take away

Knowing what functions the different components of WSO2 API Manager actually play can help you decide on your deployment strategy. You may opt to have them all together in your development environment, whereas in your production environment you may separate the design-time and the run-time components. You may also decide to deploy your Gateway in a separate network area from your Key Manager and Traffic Manager. In such a setup, the Gateway can run without a connection to your shared databases. In other words, you can keep your data safe behind your firewall. Of course, you will have to arrange for proper setup of your proxies and firewalls to provide proper connectivity across the components at all times.

All in all, there are many options to consider, and it probably will require some deep thinking how to best fit your API Manager components into your overall environment – in full accordance with your network and security principles. And we didn’t even start to discuss a multiple gateway scenario – running different API Gateways in different data centres, or different network zones – for instance to separate internal and external traffic. The possibilities are literally endless. Fortunately for you, Yenlo is there to discuss your options, and help you pick your best scenario – and  perhaps best of all, prove its viability too (which is seldom trivial in practice). After all, we’ve done it before. And we’re always looking forward to run an API architecture workshop to help tackle your challenges, or be of help otherwise.

Do you want to know which API product matches your business requirements? Find the answer in our white paper below, where we compare different API vendors and their product features.

Full API lifecycle Management Selection Guide

WHITEPAPER

smartmockups l0qqucke