C# ASP.NET - Restful APIs - do they contain, or how to handle, granular permissions?

Question

The APIs that we are writing do require authorization through a bearer token, but I'm talking more granular permissions for that User.

Let's say we had a Supervisors Controller, it would have these endpoints: Get All Records, Get One Record, Add One Record (Post), Edit One Record (Put), Delete One Record.

Our CRUD app uses this API. Imagine a grid that displays the records (using the GetAll), and with options to perform all the Supervisor related CRUD.

Well, this grid also has granular permissions that the GUI uses:

If Add were unchecked, they wouldn't get to Add (so no Add menu). If all were unchecked, the top level "Supervisors" would be unchecked, and we wouldn't even let them see the grid (they wouldn't have the menu item to get to the Supervisors CRUD). Again, the GUI reads these permissions and takes care of that.

But, I also add those same granular permissions to the API. The "GetAll" and the "Get" all ensure that the top level "Supervisors" is checked, or it returns a Bad Request. The Post checks for New, the Put checks for Edit, the Delete checks for Delete. Again, otherwise they get a Bad Request.

Here's where that becomes an issue:

Another "component" needs a "GetAll" to the Supervisors. We'll call this component Foo. Foo may need to grab all the Supervisors to fill a Combobox. Well, if they don't have Supervisors permissions, which it may very well not have (we may not want to show them a CRUD screen that only an admin should see), the GetAll will fail with a BadRequest. For Foo, they should really only need permissions to Foo and not worry about needing Supervisors permissions (or vice-versa).

I was told a best practice was to keep all Supervisor related lookups to the Supervisor component, but now these granular permissions are getting in the way.

An idea is to have an Origin parameter, but now Foo business logic is spreading to the Supervisor component -- hello switch/case statements!

Is it that we don't check granular permissions at all, and rely on the GUI? But our users' profiles (where we get our permissions) also have a concept of secure filters. So that Foo lookup into Supervisors may require a bit of sql to be added to the where clause so that this particular user can only see the Supervisors they are allowed to see. So, again, Foo business logic creeps over to Supervisors (if we used an Origin parameter).

If Foo should contain all of Foo's business logic, maybe I go to the Foo controller first? I would create a "Lookup" endpoint where it checks to see if they have permissions to Foo, and if that passes, get a secure filter returned to you. That string is now used as an optional parameter that our Supervisors endpoints can use in their queries. There's no switch/case statements in Supervisors anymore. It just checks to see if it gets an optional string or not, and doesn't care where it gets it.

I'm kind of on an island, and need to reach out, so Thanks.