PDP Response for Fine Grained Authorisation

[cyanogen12]

Hi All,

I have been evaluating OPA and thinking to apply it in my API journeys to enable authorisation. But I am little bit confused as whether my fine grained PDP check should return a Yes/ No or a JSON. I have tried to explain my use case as below.

First of all, the API flow will look like:

1. Client (makes an api call lets say /franchise).
2. API gateway Intercepts Call. API Gateway enforces PEP to apply coarse grained authorisation. Checks include:
   2.1 The API request has a valid JWT and Client is authorised to make a call to / franchise.
3. The call is forwarded to backend business Service. Business Service PEP intercepts the call to apply fine grained authorisation.

The above api journey is for ABC Ltd. ABC is global coffee chain. One of their business lines includes offering franchises to external parties. The finance department wants to have access to all franchise data. They can invoke one of the below endpoints to get franchise Data.

1. GET /franchise/{franchisieID} Return specific Franchise Data
2. GET /franchise Will return list of all the Franchise.
   The list of franchise returned by second endpoint GET /franchise will depend on the authorisation.

A user who belongs to Local State Finance department, should be returned list of franchise that belong to the State same as caller finance department.
A user who belongs to Country level Finance department, should be returned list of franchise that belong to the country same as caller.
A user who belongs to Global Finance Department, should be returned all the franchise across the Globe.

There may be 1000s of franchise in a state and in range of 10K for a country. The above hierarchy is not fixed but just an example.
In this example my question is if PDP output should be a JSON which include list of all franchise data user is authorised or it should returned just ALLOW/ DENY
That is should it be like
PDP Response Option 1:
{
“USER”:”ABC”,
“ALLOW”:true
}

Or
PDP Response Option 2:
{
“USER”:”ABC”,
“ALLOW ”:”TRUE”,
“”Franchise:”123,124……..1000
}

If I go with Option 1 then am I getting any benefits by applying this check before business service and when I have to handle franchise checks within code.

If I go with option 2 , then the PDP response could be too heavy.

There could also be scenario where there will be list restricted franchise. e.g.

GET /Franchise called by INDIA user

Authorisation rule allows on 9900 out of 10000 franchise available in India and 100 are restricted and can be viewed only by Global Finance.

IN this case should the response look like

PDP Response Option 3:
{
“USER”:”ABC”,
“ALLOW”:true
}
snd handle authorisation within code as in PDP Response Option 1

Or
PDP Response Option 4:
{
“USER”:”ABC”,
Allow: {
Franchise:”123,124……..1000
},
Deny: {
Franchise:”123,124……..1000
}
}

[charlieegan3]

Hi @cyanogen12, this is a good question, thanks for writing it up.

I think you are right in that you have two options. Either to have the PDP know or be able to compute the mapping of all users to all Franchise data, or having a the PDP return less information and letting the Business Service calculate the data required using the PDP response.

It sounds like mapping to Franchise IDs is sufficient to pass back to the Business Service to select the data to return. If this is the case, loading the collection of Franchises into and OPA and returning just the allowed ones for a given client should be fine. This allows you to offload the that functionality to the PDP away from the business service.

One thing to make sure is that you can make updates to the OPA's Franchise dataset in a timely manner. You might want to look into using the Bundle API to do this.

[codermvn]

@charlieegan3 It would be really important here to also consider that applications have some really crazy rules and putting all those business rules, like the ones mentioned here, could be really complex to maintain at an enterprise level. Won't keeping all the policy data in OPA's policy store be an overhead?
Are there any benchmark tests available that tested the performance of the OPA policy evaluation engine to throw some light and taking informed decisions on it?

Thanks :)

[anderseknert]

Hi @codermvn 👋 I think the argument is often the opposite — how do you maintain policy (or business rules, etc) across large (and often, heterogeneous) distributed applications without a central place to store, manage and distribute your policy? How do you handle policy updates? How do you differentiate policy events (decisions) from regular application events? How do you know which policy was in effect 3 months earlier when an auditor comes asking? Can you rollback your policy system to that state to see why a decision was made? And so on.. :)

As for overhead — yes, that's definitely something to think about, and to what degree depends on your requirements. Policy evaluation is commonly done < 1 ms in OPA, but unless integrated in Go/Wasm/IR, there's also the overhead of calling an external service. Distribution of huge datasets is another common concern here, but again, all depending on requirements.

[codermvn]

HI @anderseknert , Thanks. And to top it up we have integrations with multiple oAuth2.0 servers and IDP servers. Taking some of the enterprise's common attributes for users, which can be mapped to claims and then you keep on changing scopes whenever we are passing by multiple gateways, makes it a bit complex. I am not sure if there is any guidance available on that, or enterprises can choose and customize as per their needs.

[anderseknert]

Sounds like you have some interesting problems to solve then :) Although it sounds to me like the problems would be mainly on the identity side and not as much in authorization, provided you have a competent identity server.