Prevent or restrict Basic authentication on Table APIs

[Martijn Dessing]

We come across a lot of 3rd plugins that still use webhooks/direct usage of table api's with basic authentication. For all inbound APIs we as a company wanted to get rid of all , or isolate those table api use cases. Firstly we needed to enforce table api's to use at least oauth.

Secondly , when such solutions uses table api's  and still really needed basic auth, we wanted to isolate the api_user's access as far as possible.

I started looking into ootb solutions like REST API Access Policies and Machine Identity Access Controls.

I explicitly do not use REST ACLs , because sometimes these plugins use scoped apps and I do not want be bothered with that..

This is what I found out while testing:

API Access policy - > only filters for a authentication method to a resource /api path or table api

Authentication policy -> provides the authentication method (basic / oauth  ) and only provides an oauth entity to the API policy (NOT A USER) .

Machine Identity Access Control (MIAC) -> Adds an USER (NOT OAUTH ENTITY) to an API policy and selected tables.

...now that's weird... Couldn't they just have provided a user select list in the Authentication Profile form with Type 'basic' , as it does for an oAuth Entity in type 'oauth' ?

Since both API Policy and MIAC have a table selection options (in Zurich you can drill down the API policy to a specific table api !!) , This seems a bit redundant, or not ?  

So I started building and testing:

Create 1 Authentication profile for oauth (no entity)

Create 1 Authentication profile for Basic auth (no filter policy)

Create 1 REST API policy that prevents basic auth on all table api's.  (just add oauth profile)

Create a REST Policy per table api that allows basis auth (add the basic auth profile)

Create a MIAC to link the api_user to basic auth REST API , define same table(s) as per policy.

Testing API Policies back to back with MIACs, I came to the conclusion that;

If you need to provide access to a user to a table/api , you would need BOTH for basic auth use cases.

I also found out that introducing MIACs my oauth policies failed somehow !.

"message": "User Not Authorized",

"detail": "Failed Machine Identity access validation"

Also I have tried to have two api users with identical roles but allow only one user on the table with MIAC. 

And that did NOT work at all.Why?

(Have not figured this out  yet)

There is an alternative to a MIAC configuration (Aw. Yet another policy but it works!!)

Add the api user to a specific group that represents that table api resource..

Set up an authentication policy in [sys_authentication_policy]. Set the group in the policy filter input and condition (group = true). Add that Policy to a Basic Auth type Authentication Profile for the Table. Add the profile to the Table API's REST API Policy.  

If you would need multiple Authentication methods to the same table/api you could combine Authentication profiles for Basic auth and oauth to the REST API Policy for a table api. 

I have not been able  to combine MIAC with oauth Policies on the same resources. It is either one or the other.

For oauth clients with access to table api's, there is an option to add a table_api auth scope (for all table_api 's).

In Inbound Integrations in the Zurich's Machine Identitiy  Console, you will be able to created it when adding an new integration.

Did anyone else test this use case and come up with a solution to restrict table apis to users, for a certain auth type? Or any suggestions are welcome.