When REST Services are enabled in Epicor, my understand is that security is handle with Epicor’s “User Account Security Maintenance”. So users can only access data and functionality in the REST Services that they can already access in the Epicor UI.
But, we only want specific users to be able to use the REST services. How do you prevent any Epicor user from accessing the REST services? Is there some way in the Epicor User setup that I missed or will it need to be done in IIS?
Saying REST is the same as saying WCF when it comes to security. This was by design. If someone went through the trouble of setting up field and method security and then we came along and changed that and forced you to do a parallel configuration I would have been strangled by a few hundred admins.
Are you looking for a different security handling mechanism for REST or a kill switch?
FYI - In vNext, REST will be on full time and be required for the fancy new homepage that was shown off at Insights amongst other features.
We are just getting into the Epicor REST services and there ease of use. So there is an initial fear that a savvy user can type https://EpicorServer/ERP101600/api/help into there browser and figure out how to update the Epicor outside of our procedures and processes. But, we will just have to slap their hands, if this happens.
I assume the procedures are at the BPM level? In that case you are fine. REST goes through all the normal server processing that you are used to doing. The only thing that has changed is how bits fly across the wire.
Now if you ONLY locked down processes by something in the UI then I am concerned for you. Not because of REST but because any other client could break past your processes. An integration? Task Agent? Any of the growing number of clients.
Remember to call the server only takes two lines of code in C#. REST would take about the same depending on language:
//Get a session
var session = new Session(“manager”, “Epicor123”, Session.LicenseType.Default, @“C:_projects\ice3\Current\Deployment\Client\config\local.sysConfig”);
//Call the server method
WCFServiceSupport.CreateImpl(session, Ice.Proxy.BO.TipImpl.UriPath).GetByID(“key1”, 0);
Edit: If you have modeled security using menu and process securities through menu maintenance only, when switching to REST, you’ll want to map out current security roles from menu items and extend the roles to the object securities. Any REST user should hit similar security restrictions inside or outside of the application.
SOAP has its role. JSON has its role. Choose the right tool for the job - allowing that is something we are striving for. The world has changed from 10 years ago with more mobile needs and point to point solutions being used instead of multipoint solutions that WS* was envisioned as solving. That world did not evolve as the prevalent platform so we are evolving to fit the current needs.
They had rigs out in the middle of the ocean that relied upon satellite links. data was a commodity. We worked heavily on performance analysis and comparison against simple remote desktop. Another problem we had around the time was unreliable customisation conversions, hit-and-miss with reliability, which is sad to say. I hope it handles at least fairly middle-weight modification nowadays!
Ahh TRULY Satellite comms. I worked on satellite based work for tee times into remote golf courses back in the 90s. You definitely appreciate those 3/4 sec delays real fast and payload size as well. That all kind of died in the industry until mobile went nuts a few years ago and now the same patterns are back worrying about cell networks.