What, if any, concerns should I have about making REST services available? I hear lots of conflicting things about how secure it is and what can be done with the service. I know this is a pretty general question so if there is a document out there that covers this, please point me in the right direction.
Thanks,
Ed
You should have the same concerns managing your general Epicor security with REST security, since it is using the same security model. You still need to authenticate with your Epicor application (Windows, Azure, username, password.).
You should have security around user roles and objects.
You should have https enabled on your Epicor Applicaton. You should NOT have blank passwords or weak passwords (longer is better, generally).
Iâm sure others have more but this is the basic stuff.
Mark W.
I have heard the FUD (fear, uncertainty, doubt) a thousand times since REST was created. It makes me chuckle and cringe at the misinformation.
Rest services call the exact same BOs that are called via other protocols. The method and data security approaches used to lock down âlegacyâ protocols apply to REST as well. Too many have thought that menu security locked down the server as well. Nope. Thatâs why it is called MENU security not service security.
If you think you have an exploit by adding rest please review your current system. Two lines of code calling wcf services will not stop hackers. Security thru obfuscation is not security.
Learn the security around services and data to see your current exposure.
Next you will probably find that the ease of use is not ideal. That is something we have heard and weâre already exploring. No announcements yet on that but we donât like it internally in SaaS either so are internally motivated to improve it as well. Also review adding validation bpms around sensitive data and methods. Adding a check based on a group is a common approach to securing some information.
2 Likes
Thanks you for the very quick and very helpful replies!
On the topic of REST Security, I need to re-write an integration to an external T/E system on the current 10.2.300.3 version.
Epicor security has always been SSO.
For the Endpoint Binding, should it be : HttpsBinaryWindowsChannel ?
Along with this, if Mobile CRM would be implemented what is the preferred Endpoint Binding?
BTW, this is NOT a hosted solution nor Azure.
A valid point on SSO for Identity. When the term âsecurityâ gets thrown out, peoples minds go to different areas.
- Authentication of a users Identity
- Authorization of what a user (or group) is allowed to do
- Encryption of the bits flying across the wire
- Masking / Censoring of Data for a user / group
- Surface area on the app server and db server - ports, process identities, etc.
All of these are their own topics but something that needs to be thought of holistically to really tackle âsecurityâ. I have a favorite saying - âAll you need to do is everythingâ 
1 Like
If you still talking about REST, then binding is not relevant. REST does not use WCF bindings, it always work by https.
1 Like
To add onto the questions being answered here: I am trying to help ease one of our partner companies into exposing their Epicor REST services to help us integrate better with them via BAQ svc.
They have been concerned about security in REST, in particular wondering if there is anything preventing me from looking into or altering other parts of their system. Would this be the case to implement some sort of BAQ security on the set of applicable queries to ease their concerns? I wasnât totally sure how to answer them, other than that I would imagine implementing BO security and âallowingâ my set of credentials in their system a limited set of BOâs.
Yeah they should implement BO Security and or Field Security. Then in the BAQs they give you access to they can also apply security. If all they want to give you is BAQ Access then deny all BOâs except the Dynamic Query ones (My guess is this will break other things so there may need to be some slight flexibility there)
1 Like
Cool, Iâll lead with that
Another option is to add a layer between the external web server and Epicor. That way, the only thing communicating with Epicor is the web server and the only thing the external users see is the web server.
It also encapsulates the system from upgrades a bit as you wonât have a direct dependency on Epicor versioning, which youâve mitigated some already if youâre using BAQs.
Mark W.
1 Like