Advanced Distributed Data Authorisation

As organisations make the move to microservices and lambdas, data authorisation is becoming a complex challenge, where policies have to be implemented across mutliple independent services, by mutliple different teams.

Meanwhile, with heightened awareness and protections on privacy, data compliance regulation is becoming increasingly complex. In a highly regulated environment, the risks of a poorly enforced data policy could lead to very expensive data breach & penalties.

Traditional approaches - such as role based permissions on services - don't scale well across squads of multiple development teams, building hundreds of microservices.

Moreover, traditional approaches tend not to operate at the correct abstraction -- data authorisation for read operations isn't really about services - it's the underlying data that really matters.

Modern data authorisation needs to reinvent itself, to answer two key questions:

• How do we secure data, regardless of where it comes from?
• How do we enforce data policies consistently, (and affordably) using an approach that scales across hundreds of services and teams?

Fine grained data authorisation with Vyne

Vyne is an AI powered integration platform. It provides an intelligent API gateway, which allows callers to focus on data, rather than services - API calls are framed as "Given this, find that" queries, which Vyne automates as a series of calls across your API infrastructure - adapting and problem solving along the way.

Vyne has a deep understanding of the data being returned - down to the individual attribute level. This makes it a natural place to define and enforce enterprise-wide data authorisation policies.

Vyne - An Introduction

When operating through Vyne, callers submit a query to the API gateway. Vyne builds a query plan, calling services to discover the data neccessary to build the query result.

Let's look at a quick example.

Let's say we're working for Jarbucks Coffee Emporioum, we have a customer's email address, and want to look up their account balance on their rewards card.

This involves a few hops:

• Use their email address to look up their customer number
• Use the customer number to look up their card number
• Then, look up the account balance.

Here's the flow:

Vyne automatically builds a query plan to connect the services together and discover the account balance from an email address.

Making it secure

Consider a new requirement emerges:

"Only the account owner may see their rewards card number"

Our current architecture exposes the rewards card number in two places:

• On the response of the RewardsMembership call
• On the final account balance object

Traditionally, adding this new rule would require updating both of these services with the new rule - checking the principal of the caller, and filtering the cardNumber attribute out of the response before sending.

This requires engaging two different teams, each who need to embed the security policy within their code - representing both a high initial cost of investment, and subsequent high cost of change whenever the policy changes.

Enabling attribute level security with Vyne

This requirement is trivial to implement with Vyne.

Vyne's UI allows us to create and attach policies to data types. These policies determine who is allowed to read data - right to the individual attribute level.

The process to create a policy is simple:

This policy defines that in order to read the AccountBalance data type, the requestor must be the person who owns the account.

Notice that in our example, account balances use the "LoyaltyDepartentCustomerId", not the actual Customer Id. Vyne understands this, and automatically performs service calls to map LoyaltyDepartentCustomerId to CustomerId when applying the policy.

By defining a policy in this manner, it's automatically enforced against all data being returned, regardless of the actual services involved. Also, the underlying services are free to change their API - the data policy will continue to be enforced automatically.

This data policy is activated immediately - without code changes, build times, or restarts.

Futhermore, Vyne understands the difference between serving data to users and to services. The implications of modifying data being sent to a service can lead to unintended consequences. Therefore, Vyne optionally allows configuring if policies are applied to all callers (inlucing other services), or only to users.

Summary

Vyne lets us define policies independent of the services that serve the data. As a result, these policies are enforced consistently, and very quick to build. The services that serve the data are free to evolve their APIs, and Vyne automatically adapts - this lowers overall cost-to-change, and reduces release friction.