Maybe a new topic … But how secure is using a web browser as your user interface? Granted companies should have control over what browsers (and browser extensions) that their people use. But an errant extension / plugin could sift off data.
And yes this would be an issue with anything done through the browser. But there’s no “WeatherBug” or coupon plugin for the native client.
And do browser features like Autofill play nice with the Kinetic interface?
And what about those users that know how to press F12 and puck around in the developer mode in a browser. I could put a breakpoint in right before that REST call (assume that’s how it updates the server), and tweak the data being passed to it.
Yes, Autofill seems to work. I have an app called LastPass that remembers logins and passwords for any page that has those. LastPass auto populates my login data & password when I launch Kinetic.
I use LastPass too. I know that LastPass encrypts everything you save - in a way that they can’t decrypt it (or so they claim…) .
But what if a less reputable password manager was being used by employees, and that company suddenly was acquired by a company with ties to Beijing?
Does Kinetic rely heavily on the fact that you shouldn’t make it available outside your firewall? And require remote employees to use a VPN or some other access method instead of just a generic internet connection?
I have several Epicor sites that I can access while outside of a firewall… then others that require me to be inside the firewall. Obviously, being in the firewall forces an extra layer of protection. I am not a web security expert, but I believe that the “https:” prefix and the way that you must connect via security should protect your data just like when you connect to your local bank or your amazon account without a VPN.
My thought wasn’t about a bad actor sniffing the traffic between my computer and the server. But about the ability of anyone with a valid E10 username and password, being able to interact with your server, from anywhere in the world.
How many systems will be exposed because the still use the default password of ‘manager’? With on-prem (and no EWA), you have to be physically inside your firewall, and have the client installed, to login and interact with the system.
shame on anyone who leaves Manage/Manager as an open password on their system 
That said, yes, if the system is outside the firewall, then the site can be accessed from anywhere in the world, just like your bank account. This is why passwords and multi-factor authentication is so important.
Security is a bigger topic. Do you mind if I start a new thread?
Not at all … In fact I jumped in with …
You can do that now in the Fat Client too… Epicor is built on an SOA Architechture meaning every request goes through a web service (rest or not)
That means you can intercept the call (Fiddler, WireShark) and alter the payload to your hearts content. The security comes from the individual user’s permissions (you are still beholden to those) and the sound business logic (one hopes)
Kinetic will make it a little easier to fudge with the payload but again you’ll still be beholden to your individual user’s security.
If you are considering enabling your ERP System outside (in the WAN) then you need to really tighten your reigns.
You need to implement IDP Security within Epicor and Two Factor Authentication, consider going to something like Azure AD perhaps with multi-factor authentication
You need to enforce lockout policy (prevent brute force) and disallow simple non complex passwords in the system (all of this can be done in Epicor out of the box)
That is your biggest concern, but if you keep it inside your LAN, then the security implications are the same as the Fat Client.
We just finished working on a portal POC to put outside the WAN and we weren’t comfortable with just the standard security so we went a step above and implemented a middle-ware (software that steps between the two end points) that does additional security analysis and scrutiny
Epicor tightened up their security quite a bit with the release of REST V2 which requires Scope and API key, however V1 is in the same endpoint as V2 and if you make V2 available you by default make V1 available (unless you take extreme measures)
Roughly ten years ago, a man named John Kindervag came up with a new security strategy in response to data breaches: Zero Trust. At that time, most IT professionals scoffed at the idea. The culture was (and mostly still is) to protect the network and put your valuables inside it - because whatever’s on the local network is trusted and safe. With every ransomware attack we see, this has been proven to be a very poor assumption. Over the last couple of years, many have come to the conclusion that a Zero Trust architecture is the best way to move forward. It is the official recommendation by NIST. Zero Trust Architecture NIST. Microsoft has gone all-in as well.
In short, Zero Trust says that security should be built from the inside out and not the other way around. Microsoft summarizes Zero Trust into three actions: Verify Explicitly, Use Least Privilege Access, and Assume Breach.
Verify Explicitly
This means that we use everything available to the Identity service to verify the person and/or the device. Is it a device I know about? Is it in an IP range that I know about? Has the user passed a local verification check (fingerprint, retina, face, etc.) on the device? Did they use Multi-Factor authentication like a dongle or a phone? Is it normal business hours for this user? Was this request made in a location that is close enough to travel to since the last request? The answer to these questions create a risk score and the ability to access critical resources may be limited by a lower score. Using just a username and password in Epicor (or any other system) cannot give you this kind of verification.
Use Least Privilege
Once authenticated, what can you do? From where? For how long? What resources are available. This mapping is a LOT of work but it’s infinitely better than the current trust practice. John has a quote, “Honey, who is the man taking beer from our refrigerator? I don’t know but since he’s in the house, it must be OK.”
Assume Breach
Honestly, there really is little difference between our internal networks and the Internet. We should treat all of our networks as if they are open to the Internet because during a breach, they essentially are. How can we limit the blast area during a breach? Did we segment our network? Do we have honey pots set up to detect breaches and automatically react to them? Watch the news. It will happen to every company and if it’s already happened, it will happen again. So plan for it.
As for Epicor, the Rich client is no more secure than the browser IMHO. Both are susceptible to key logging, both can be attacked by supply chain methods (3rd party libraries), and neither is a source of safety to input - the server should do all checking after all.
Finally, passwords are a disaster and we’re starting to see proposals to eliminate them. If you enable Azure AD login, passwordless authentication would be available to your Epicor system in the cloud or on-prem.
Here’s a video of John Kindervag at a conference talking about the Zero Trust journy of one of his clients. Implementing Best Practices for Zero Trust You can find many other videos about Zero Trust from many other companies on YouTube as well.
If you’re a Microsoft shop, here’s a list of the new Security Certifications available:
Introducing Microsoft’s New Security Certifications - Microsoft Tech Community
I had forgotten that there are cloud services to make both more secure: published apps (via virtual terminal services) and browser isolation services. Recently, Cloudflare started a browser isolation service. Both services are clever ways to segment your network and reduce the blast area of any intrusion.
My initial thoughts (which may be way off base) was that if the functionality that normally happens in the client is now processed via javascript, some controls could easily be bypassed.
Like how does making a field read only work?
Do all customizations now need to be done on the server side, via BPM’s, field security, etc…?
I guess one of the points in my lengthy post is that the client should not enforce security. The REST call only occurs over an authenticated connection. There are no “anonymous” posts. Any altering at the client should still be checked at the server.
Customizations in the .Net client are technically done on the server side too. 
But from a programming point of view, we really should separate the client code, from the business logic, from the data repository. (Model-View-Controller for example). I think we’ve gotten into some bad practices by putting business logic/security into our client customizations over the years.
If one takes the Zero Trust approach then we should do less of this in Kinetic. I think that Application Scope is a very powerful tool in addition to Service/Field Security, BPMs, etc. for explicitly granting privileges with finer grains of control - most certainly for service accounts that interface to Epicor.
Here’s a scenario: The company does not want to allow users to change the Prod Group on the sales entry form. Whatever populates from the Part table should be used.
The simple solution would be to make a customization and use extended properties to make the OrderDtl.PrdGrp field read only. I’d bet dollars to donuts that this is the way a lot of people would solve this.
Now changing that prod group would be very hard to do in the smart client. But in a browser based UI, I could hit F12, edit the field (or find the variable holding that value and edit it) before saving the line.
You’d have to add a BPM, to check the received update, to make sure the ProdGrp on the line matches the prod grp of the line’s partnum.
Or is something else going on when a OrderDtl record is updated? I was under the impression that the customizations only affect the data in the clients local memory. And that something like the Extended Properties Wizard’s functionality wouldn’t actually be know by the server, and thus not be applied to the server side processing.
And I’d bet dollars to donuts that the reason we’ve done it that way is that’s how we would have done it in a single user system (like Access, FoxPro, etc.) and that carried over to the VB client in Vantage, which carried over to…
For me, the simple solution is the Extended Properties AND a couple of BPMs. For new OrderDtl records, change the Product Group to whatever the Part Product Group to display to the user. To really enforce it, use a Data Directive to set the value on updated/new records. Finally, I may even create a monitor to run once a day to check and see if indeed every Product Group on uninvoiced OrderDtl records matched what was on the Part to catch any edge cases we may have missed.
Why? The rule now applies not just to the .Net Client, but to Service Connect, to DMT, to REST, or even some 3rd party interface using WCF - any of which could defeat the customization’s business rule as easily as pressing F12.
AND… this is why I ALWAYS push any validation and security logic to BPMs instead of the UI… Also, my last big project had orders coming in from multiple sources: EDI, Epicor Commerce Connect, Quote Conversions and Manual Entry. Only one of those actually uses the UI, so to make the validations work, we needed the BPMs to fire to validate and set defaults for all new orders. BPMs are the central way to make sure that things are done correctly.
I’d like to think that most people use UI customization as hints or shortcuts for data entry.
But the do work well then objective is “Prevent the user from changing _____ on the form”. Which is not the same as “Prevent _____ from being changed”
This approach is going to have to change, it was never a secure approach to begin with. They should be using field security, BO Security, BPMs and Data Directives to stop someone from editing a specific field.
There’s going to have to be a lot of adjustment to the way everyone does things. Does putting it in the browser inherently make things less secure? no… because what we did before gave us a false sense of security
In the fat client if you want to edit a read only field (client side customization) all you need is to intercept the call (like you would in the browser) or use one of the many free .NET Reflectors (DnSpy FTW) to change the field properties on the fly
Is it ostensibly easier to do in the browser? Maybe… but again that’s just false sense of security soo doing it this way would ensure we all have to go back and fix our crappy insecure approach.