Remember, REST is calling the BOs for you. Any restrictions you put on the BOs through field and service security will also be enforced in REST. Only MENU security is not enforced by REST - because there is no menu.
I wholeheartedly agree with Jose. One really must think about security differently. Today we have:
Security IDs which control Menu and BAQ access
Process and Field Security which is done by Security Group (and Users but don’t do that)
Scope and API-Keys but only for Integration Accounts.
What would be nice:
To be able to assign permissions base on a capability - Can Add, Update, View, Delete, or Process. This helps with overloaded apps like Customer, Part, and Supplier where people should have rights to some but not all of the command.
Ability to Mask all data types (all types and not just characters). This alone would reduce a large number of customizations (that don’t really stop REST calls anyway).
Add a layer of abstraction that combines capabilities above into roles. This where one would enforce SOX controls by preventing certain capabilities in the same role without some compensation.
Still provide a way to control some security through Directives for difficult edge cases and blocking Security Managers to get to a more Least Privileged world.
Bonus: Integrate the Security roles with Entra ID or Epicor IdP to be able to enforce MFA or conditional access for sensitive Kinetic commands.
Yes… I don’t know how to articulate this which is why I don’t know what to ask for in a Kinetic Idea… But it’s basically REST calls where the code is not written by Epicor or an “approved” 3rd party app… I realize this does not give you anything tangible to work with lol.
No, I mean if a user makes REST calls by just using Kinetic in the browser, that is not “custom”, and wouldn’t be subjected to this additional security. But if they hit the endpoint url from Postman or some .NET app, whatever it may be, then block this outright even though the user credentials passed in that call allow them access to the BO. Basically force anything “custom” to use an integration account where we can use Access Scope configuration.
Maybe I am grasping at straws… If you can’t tell, I am looking for some kind of shortcut for Service Security implementation.
I don’t think so. Authorization happens at the server. You want to block any client that isn’t the official web app. I can’t think of a way…that doesn’t rely on security at the client. So it’s just kicking the can down the road.
I don’t see reliable way to tell who call the REST endpoint. Whatever property is set on the client side to declare that it is valid Kinetic client, you can always set it as well in your custom application/PostMan. It only requires Dev Tools to figure it out.
You have to limit access on the server side.
