5 considerations when implementing multi-layered API security

Multi-layered API security cannot be added in later and must be considered from the get-go. This is not as simple as it seems though. In this article I look at some of the challenges involved with developing systems with multi-layered security.

Start with security requirements

When designing your product, one of the most important things to consider is security. The security requirements provide the rules for:

• Relationship between users and customer accounts
• Relationship between users
• Access rules governing the relationships between users, accounts, purchased plans and your products resources

These requirements will help identify the security architecture you need to put in place and the security that you need to apply to your APIs.

API Access

Most contemporary systems have one or more APIs that define a set of endpoints. Each endpoint allows you as a user (or as another system) to access a resource being managed by the system.

A resource may be an account, a workspace, a document, a comment or any other piece of private information.

Access to a resource does not just mean reading it but may include creating a resource, updating a resource, deleting a resource or even reading meta-data about the resource, such as audit trails. Each endpoint in the API represents a particular type of access.

Clearly it is important to secure all access to the resources managed by the system.

Authentication vs Authorisation

Security has two components and it is important to understand the difference between them:

• Authentication - determining who or what (may be another system) is asking for access to the resource
• Authorisation - determining if the access being requested should be permitted or rejected

Authentication is basically the process of 'logging in', whereby your credentials prove who you are as a user of the system. It could be as simple as providing a username and password or it could involve Multi-Factor Authorisation (MFA) involving codes and authenticators.

Authorisation is making the decision as to whether the authenticated user can be provided the access they want to the resource they have requested.

Security policies are rules that are used to decide if authorisation should be permitted or rejected. When a request comes in, it is checked against all the relevant security policies. If any reject the request, the user access is rejected. If they all permit the request, the user gets the access they requested.

Multi-layered API Security

Now, let's look at what I mean by multi-layered API security. I am talking here about the authorisation of the request rather than the authentication.

I see a lot of different solutions for implementing API security. In its simplest form, the only requirement to permit a request is that the user is authenticated. This single policy basically says 'if you have successfully logged in', you can do what you want. This is almost always a bad solution.

A modern, secure solution has multiple API security layers, as shown in the following diagram:

Following authentication, the request for access, received by an API endpoint, is assessed by each of the layers in turn. At any point, a layer can reject the request and the request goes no further. The request is only permitted if all layers permit it.

The policies implemented at each layer become more sophisticated, starting with simple policies at the RBAC layer and the most complex at the CBAC layer. This allows each subsequent layer to make authorisation decisions based on more information. This provides a more secure and a more performant solution.

You may recognise that these layers extend deep into the application itself. In fact, each line of code written by a developer should consider the security architecture and frameworks should be designed to minimise the chance of authorisation errors

RBAC - Role Based Access Control

For many decades this layer has been the staple of the security world. Each user is given one or more roles. Each API endpoint implements a policy to permit a request based on a given role. The user is only permitted access if they have the given role.

This is a simple and fast policy to invoke. The authentication process generally provides the list of role that the user has and the first thing the API endpoint checks is that the given role(s) is in the list.

The downside of this layer is that if you and I have the administrative role, we both have the same level of authorisation. For many systems, this is not sufficient.

ABAC - Attribute Based Access Control

If I use a system to record a private note, I do not want you to be able to access it.

It can be seen that RBAC layer may allow us to both access notes because we both have the required role but I still do not want you accessing my note.

This is where the ABAC layer comes in. Effectively the attributes held with the resource determine who can access it. This means that the resource itself is used in the decision to permit or reject the request.

In the example of the note, I am recorded as its creator. The ABAC layer has a policy that says 'Only the creator can access a note'. This policy ensures that you cannot access my note.

CBAC - Context Based Access Control

The next layer of security is based on the context of the request. Depending on what you are trying to do, when you are trying to do it and why you trying to do it, the policy decides if you should be permitted access.

For example, I may want you to access my note if I have asked you for help. In this case, when you access the note, I want you to be able to see it.

Determining context can be difficult to determine and will depend heavily on the business logic in the application.

You may have come across platforms that provide you with a customer care PIN. By providing the PIN to the agent, the agent can then prove that they are accessing your information as part of a support request that you have initiated. This proves that the CBAC policies should allow the agent to access your details.

Challenges with multi-layered security

When you implement multi-layered security, there are a number of things you need to consider. In my opinion, these 5 are the most significant:

1. Performance
2. Lists
3. Multi-tenancy
4. Random Access
5. Testing

1. Performance

Security is a balancing act between three competing requirements, as shown in the following diagram.

1. Performance - the more logic you add to a policy, the more information that must be fetched and the less performant it will be. Access will become slow and usability will suffer.
2. Accessibility - the more important that a resource is, the more security you will want to add to it. Imagine you had bars of gold at home, you would be tempted to add more locks to your doors and windows. The impact of this is to make it hard to use the system (eg: for you to get into your house).
3. Usability - users will get very frustrated by systems that are determined not to allow them to do what they want to do or even what they need to do. Generally the more usable you make a system, the less secure it is.

Depending on what you are securing and the user scenarios you are looking at, you will need to balance accessibility, usability and performance.

This balance will depend on the frequency of access, the sensitivity of the resource and how quickly a user needs to do something. This may require different levels or RBAC, ABAC and CBAC to be applied.

You may have seen on some platforms that to access certain information, you need to re-authenticate or jump through a few other hoops. This is an attempt to balance the security triangle.

2. Lists

This might seem like a strange thing to highlight but it is actually a critical consideration.

Let's say I have a work desk and on that work desk there are a number of folders. You are allowed to access the desk but only some of the folders.

The ABAC policies allow you to access the work desk and to list the folders. However, the ABAC policies need to be applied to each folder to determine if you can see it. If you are not allowed to see a particular folder, you should not even be made aware of its existence.

This requires ABAC policies to be applied against the request coming in - and - the information going out.

I have seen many solutions that do not consider this and let you see all the folders. When you then try and open a folder, your request is rejected but, by now, you know of the folder, even if its name is confidential

Applying ABAC policies to the outgoing response needs to carefully consider the creation of resources. Depending on your transaction management and the implementation of your ABAC policies, you may need to force a flush to ensure the outgoing policies do not strip out the presence of the resource you just created.

3. Multi-tenancy

If your platform is a Software as a Service (SaaS) product, you will have different customers on the platform. Whilst it is appropriate to consider provisioning different instances of your platform for different customers, this is not efficient for a number of reasons I will not go into here.

It is preferable for your platform to be a multi-tenancy platform, ie able to support multiple customer simultaneously.

With a multi-tenancy platform, it is very important that the separation of the customer data is absolute, all the way from the API endpoint to the database. There are several ways in which this can be achieved and the solution will depend on the requirements.

There are cases where this strict separation does not meet there requirements of the product. For example, in one product I developed, there is a requirement to allow one customer to invite users from another customer to access their own resources. In this case the strict separation of the customers becomes blurred. It is imperative that all layers in the security architecture are coordinated in processing the requests to ensure that, based on the context of the request, that a user is only permitted access to another customer's resources providing the original customer has given permission to them.

Whilst OAuth solutions exist for some of these scenarios, they do not cover all layers of the security architecture and logic may need to be built into the application to meet the requirements. When this is done, it should be designed to be implemented in a consistent manner to reduce the risk of holes in your security.

4. Random Access

In this discussion so far, the request for access to a resource is determined by the combination of user, resource and context. However, this does not identify the challenge associated with resource hierarchies.

In the example above, I talked about a work desk holding folders. Let's extend that and say that the folders have different pages in them, some of which you are allowed to see and some you are not. And let's say that you are also allowed to read some paragraphs and not others. Let's say that each paragraph has its own URL and there is an endpoint to send you the content of the paragraph.

It is is easy to see that you have the role to read the paragraphs and hence you are permitted to read them by the RBAC layer. It is also easy to see that you have access to the paragraph and hence ABAC also permits you to read the paragraph. And let's say that the context you are in, also allows you to read the paragraph. All good, so you can read the paragraph - right?

What happens if someone marks the paper or folder as not accessible to you?

It is easy to think that as you access each layer in the stack, work desk, folder, paper, paragraph, your access will either be permitted or rejected. When you get to the folder, you request is rejected and stops you from going further.

However, the paragraph has its own URL and this allows you to access it directly. Your security architecture must allow for this by checking each of the surrounding resources containers (the paper, folder and work desk) to see if you can have the access you are requesting. If any reject your request, you do not get access to the paragraph.

There should be no way to bypass security.

A related issue is that of notifications. It is tempting to add information about a particular event to the notification. This means the user does not have to log in to understand the notification. This, however, is a security leak that must be plugged. Minimal information should be included in the notification and it should force the user to access the resource through the API. This ensures that any change in the security hierarchy or even in your account (eg: change of roles assigned), will be enacted and will determine if, at the point of access, you still have access.

5. Testing

With each layer, the number off security options that need to be tested increases. With 2 roles (user and admin say) at the top, only 2 tests need to be carried out. Now you add in 20 types of resource and the number of tests increased to 40. Add in the number of types of access, say 6, and you are now at 240 tests - and that is just for the happy path. Start considering edge cases and this could easily increase to 2,400.

Now consider the context. Context could also include different types of users, say:

• Trialist
• Expired account
• Basic account
• Premium account
• Invitees
• Delegates

Here there are just 6 and I have not included the different context they may find themselves in but already the number of tests has increased to 14,400. This is a huge amount of tests.

One thing is for sure, it is impossible to undertake 14,400 tests manually each time you wish to deploy your system. The only solution is to automate the security testing to ensure that there are no gaps in the architecture.

With so many combinations and the need to ensure the security is watertight, testing needs to be carefully thought out to ensure maximum coverage through intelligent design.

Both unit and integration testing should be utilised. Unit testing should be used to verify the ABAC and CBAC policies.

Once you are confident that these work as designed, across the different types of user, you can now select a limited number of test scenario that you can use for integration testing. You can also add in RBAC testing into your integration testing.

Whilst this strategy limits the number of integration test you have to undertake, it is important not to miss important integration test scenarios that test the combination of RBAC, ABAC and CBAC logic. This includes the consideration of hierarchical resources.

Testing security is made more complicated by the need to mock users and the need to mock all types of user. The level of mocking can bypass parts of the security chain and so, when it comes to integration testing, you should attempt to ensure a minimum level of mocking.

Summary

Any modern SaaS platform needs to consider a multi-layered approach to authorisation. You will find that you will need to:

1. Balance usability, accessibility and performance
2. Apply security on the incoming request and on the outgoing response
3. Consider how you will manage authorisation in a case whereby a customer may need to invite other customers into their account
4. Determine if there is a requirement to apply security policies in a hierarchical manner, confirming access to each successive container resource
5. Plan how and what you will test automatically in a system that has multiple layers, multiple resource types and multiple user contexts

Ensuring a complex system is secure is a difficult task and one that needs to be carefully considered. As I mentioned in one of my other articles, you cannot cage an elephant one bar at a time, the same is true of all security - you have to ensure your system is fully secure at all times during the evolution of the product from a Minimal Viable Product (MVP) through to a mature product.