All difference in security is API key requirement by default. Other than that security is the same, as it is centralized.
1 Like
I’m not really trying to start an argument but…
Ehhh - Is it though? I think that’s a more nuanced answer.
I lied, I am 
, but not specifically with you. YOU are my hero. 
It provides some nice security features to you as a programmer, or you as an administrator, but beyond defining access scopes for external stuff that uses REST, it really does nothing for you.
Maybe in the future we’ll be able to turn off REST V1, but for now, we can’t.
99% of the Kinetic UI uses REST V1. Except for a few specific cases like Epicor Functions.
My
Edit: That being said, I of course use V2 99.9% of the time.
Unless you setup API requirements in V1 if you expose your API endpoint to the WAN you are giving free reign of your ERP to any valid user because unfortunately most folks do not use process security to limit access they use menu security and via REST menu security is completely ignored.
So 1 user who has access via menu to a single dashboard or BAQ would via V1 have run of the system except security manager functionality.
1 Like
Cloud user here 
Perfect try it out, I don’t know if V1 is exposed in SaaS, but create a dummy user give it access to 1 security group (or no security groups) and then run REST V1 Get AR Invoices… or… Payment Entry Post a Check 
(note some of these I haven’t tested but I have tested a bunch of other endpoints and for sure via V1… any plain old user can do almost anything)
1 Like
It is.
Now if I am missing something, please inform me, but if you expose Kinetic at all to the WAN, V1 is going to be available is it not? Kinetic UI won’t run without it.
Tell me I’m missing something.
(Maybe some super magic auth from the login where Kinetic UI can use it but no one else can?)
Yes I believe that Kinetic UX uses V1 (mostly) you can enable API Key requirements on V1 and I believe that would limit exposure. However I don’t know if / how that would affect kinetic UX or if there’s a way to register an API Key in Kinetic uX to use in the app.
1 Like
I was hoping you did So we’re in the same boat.
Either way I stand by my original statement use V2 for everything, and if you aren’t in SaaS block external WAN access to V1 endpoint.
Only if you use classic UI, no kinetic forms. Browser UI uses v1, and in any case browser is not supposed to use API key as it is not possibly store it securely there.
2 Likes
So my point is - if you use functions you have to use v2, otherwise use whatever you like.
If you worry about user access, use 2FA
3 Likes
As Olga says, use MFA to protect authentication. For authorization, companies need to do some work. I’m working on creating all new SecurityIDs based on capability. (can.view.financials, can.add.ApInvoice, etc.) Then use Security Groups to create the personas and check for conflicting combinations.
Speaking generally, and not just for Kinetic, API-Keys add an extra layer of authorization and a layer of ephemerality to the end point. An API-Key limits the scope of access to an end point. A person with one key can do more things than another. We can remove a key and rotate it without having to reset all the user’s passwords. A key can also expire after an amount of time when you want to give access for a fixed amount time like for an auditor, a consultant, or an employee covering for another. Used properly, the API-Key is a powerful security tool that fits well with a new security paradigm.
The current security triad is Confidentiality, Integrity, and Availability (CIA) but Sounil Yu came out with an additional triad to go with it: Distributed, Immutable, and Ephemeral (DIE). There are several videos/podcasts of him talking about it. Here’s one below, It’s worth a listen even though it’s a bit of a sales pitch for his company. But you can find others like this podcast with Ann Johnson, Corporate VP of Security, Compliance and Identity at Microsoft.
Here are slides from his CISA presentation on the new triad.
I thought only v1 works for excel/odata?
nope, we got v2 working
How?
On the OData feed or another?
As part of our safety net V1 is blocked via routing rules externally. V2 is only exposed for our customer portal and website integrations, which are then scoped via APIKey and Service specific Epicor Users.
As an extra layer of the onion, our Epicor server is behind Cloudflare on the WANs.
1 Like
I think all of it, but I’ve slept since then.
There’s a lot in that thread, but it sounds like it only works with api key + basic auth? We’re SSO so that’s still not a solution for us. Granted I haven’t tried it since I have been told it doesn’t work.
Be bold, people lie all the time!