Batch authorization requests

[mihaidma]

Especially in UI cases the need arises to do a set of multiple authorization requests to check if the user is allowed to see or not certain UI controls. It would be useful to be able to do a batch of authorization requests to reduce the number of authorization requests sent to Udaru.

I am thinking that to implement such functionality we would need to have a generic implementation, maybe something like: https://github.com/hapijs/bassmaster

[simoneb]

There are two possible ways I can see this could be implemented:

1. Given an action, give me a list of all resources where I am allowed to perform such action
2. Given an action and a list of resources, tell me if I am allowed to perform such action on each of the resources

[mihaidma]

I was thinking more at a list of actions on a list of resources but @simoneb raised a few good points to be considered.

[mcollina]

I think this should be exposed as a new endpoint/core function, rather than something provided by an hapi plugin. There is probably a lot of work that can be shared by the requests, and it likely add a significant amount of latency and load of the server.

[simoneb]

@mihaidma that would be ultimate flexibility, but I'm thinking if this would make the API interface a little less clear. The response would basically be a matrix where, for each action and each resource, you're told if each action can be performed on each of the resources. We currently don't need this flexibility, but open to discussion.

I also agree with @mcollina that this should probably be a new endpoint which follows a different code path, rather than extending the current endpoints.

[paolochiodi]

As discussed in previous issues I'm against solution 1, because it is impossible to implement in a clear and useful way.

The problem being that udaru doesn't have a list of all resources, but only a pattern to match resources. I.e. if a policy allows write for teams/* udaru is not able to return a list of all teams that policy gives wright access to. Passing back teams/* is also not good, because: a) it requires the client to re-implement udaru's pattern matching b) doesn't account for conflicts between allow/disallows and resolution mechanism for such conflicts must be re-implemented by clients c) doesn't account for udaru variables and context

[simoneb]

Would solution 2) we more feasible to implement then? Because if I had to choose that would be my preferred option as well. It's basically just a conceptual extension to the current /access API which allows you to check access to multiple resources at the same time.

[paolochiodi]

Yep, that would be possible

[cianfoley-nearform]

So are we saying in the request body send up a list of resources and a single action? or an action against each? and in the response, return the list and the effect (true/false) for each?

[simoneb]

@cianfoley-nearform for our specific use case a single action would be enough. The response would be as you describe in either case.

[floridemai]

Hi guys,

I don't see why we want to limit ourselves to just one action and multiple resources. The check access endpoint returns true/false for an action/resource pair. The only thing we ought to be doing here is to save the user from making a lot of requests and do it all at once, in a batch. I think is should be naturally that you pass in a list of pairs and it returns a list of true/false values for each of the pairs. The caller can easily setup the array (pairs) with the same action if that's the use case.

Am I missing something?

[mihaidma]

Agree with @floridemai . Also agree with having a separate batch check authorization endpoint. This is the main use case and needs also to have acceptable performance.

Batching for operations like create team would not be a usual need and also is not a regular/intensive operation like the check access one.

[cianfoley-nearform]

Agree @floridemai @mihaidma, and that's the way I'm implementing resource/action pairs with the result being resource/action/access triplets.

[simoneb]

Ok awesome guys!

[cianfoley-nearform]

merged and released :-) 5.1.0