Secure API Access - API used by multiple User types

[Tim_Jones]

In this example, I have the following tables:

• Users
• Addresses
• AddresssAttributes

Users can have Addresses, and Addresses can have AddressAttributes.

I have an API to update an AddressAttribute. I want to limit access to the API for obvious reasons. I have three unique needs to update an AddressAttribute:

1. The user with the AddressAttribute
2. A customer service person updating the attribute for the user
3. A system process updating attributes

I’m looking for suggestions on how to lock down access to the updateAddressAttribute API for these three use cases.

Thanks,
Tim

[mark-piller]

API services can be secured based on user roles. To set roles permissions for an API service, select the service and click the lock icon:

In the popup that opens up, click the ROLES PERMISSIONS tab and assign the permissions to invoke your service method(s) to the corresponding role.

If you do not have specific roles for the users in your app, then it would have to be in the service logic to check if the user can or cannot invoke the method.

Regards,
Mark

[Tim_Jones]

Oh, that is nice. Thanks, @mark-piller. That works perfectly to lock down an API for our customer service team and to limit outside access.

Follow-up question.

For the standard User, I also want to lock the API down so a user can’t update other User’s AddressAttribues. Because an AddressAttribute row could have been added by a customer service person, or a server process, I cannot guarantee the ownerId is the same as the logged in User. Is that a mistake, and the ownerId should always be set to the User.objectId that it relates to, regardless of how the row is added?

Or should I join all the way back to the User table every time to verify ownership?

Thanks,
Tim

[mark-piller]

The ownerId column is used only when you apply the Owner Policy rules for data retrieval/update. If you haven’t done anything to configure owner policy, it doesn’t matter what value the ownerId column has.

Regards,
Mark

[Tim_Jones]

I have not applied the Owner Policy rules. Do you have a handy link for me to review that?

If that isn’t done, do I need to join back to the Users table to verify ownership?

Tim

[mark-piller]

@Tim_Jones

I have not applied the Owner Policy rules. Do you have a handy link for me to review that?

Please see this:

How to get objects that "belong" to the logged-in user (Owner Policy explained)

As the users of your app create new things objects in the database, the use-case of retrieving data that “belongs” to the user comes up quite frequently. Whether your app users create orders, invoices, or social media posts, the mechanism for retrieving data that’s associated (i.e. belongs) to the user is important. In this recipe, I will describe the simplest and the most secure way to get the data that belongs to the currently logged-in user. Let’s review some background information first. It…

@Tim_Jones

If that isn’t done, do I need to join back to the Users table to verify ownership?

I don’t know, I don’t have a full grasp of the schema design in your app and what this would accomplish.

Regards,
Mark

[Tim_Jones]

Thank you, @mark-piller! I lost track of this reply, but I wanted to make sure I got back here to say thanks for the information.

Also, I love the holiday theme on the support software

Tim