Thanks for the warm welcome Mark!
We are on the EMMW/EKW bandwagon, too, now, and obviously I, too, am setting up another āapp serverā endpoint for this, since the existing endpoints are SSO and https and all that good stuff.
My question is about security. I am really clueless with this stuff except HTTPS = good.
Can anyone ease my fears about this? Are there steps that I can take to make this kind of connection more secure? Iām already upping the Epicor password requirements since we will have to use those now for the first time since we opened up the server to integrations.
EDIT 11/11/21:
OK, I feel better as I dug into this. Again, remember I am ignorant on this stuff.
It finally dawned on me that the entire server is SSL protected, not just the endpoints. What I mean is the node I blacked out in the tree in the picture is where the certificate is applied. I was thinking it was on the EKW āapp serverā instance. So thatās good to know. And then also read on about our discussion on access scope.
Oohā¦
This would be usefulā¦
Iām using an Access scope to expose APIs for salesforce from a dedicated appserver. Seems to work well. But wow, that config file would be better, I think - can you let us know how it goes?
We have EMW on its own appserver too.
I would think so, too. The access scope line just happens to be below the CORS setting you are told to check and I happened to see it.
I will update. I have hit a roadblock already, unrelated to this, with a license error. I just put in a support ticket; I assume they will at least be able to get me set up.
I think Iāll have a bunch more questions about this app, but those will be separate threads, as I am already hijacking this oneābut I do think I am on topic so far.
oops, didnāt notice, and completely forgot about it from last year. Tag me if you remember to, very interested
Just getting started with the app server setup (access scope specifically), but here are things I learned so far:
First, ta da! That Access Scope for the whole server is a dropdown already!
Then the fun of figuring out EVERY BUSINESS OBJECT that it uses. Oh baby.
Iām up to here so far. All I have done is ship and receive and try to print. And log in.
The ones in blue are the bare minimum to log in, if I recall. Lots of trips to the Event Viewer today. [EDIT: There is another way, too. The app itself has a āSystem Logā that contains those errors, too. Itās in the menu on the top right.]
I did throw some others in there because I assume I will need them eventually. My main concern is trying to block something stupid like a Qty Adjustment being done from the app even though that user doesnāt have access to it in regular Epicor.
Although, for all of this effort, I do wonder if I would just be better off with some BPMs. Meh, this is fun and more exhaustive, I figure. (And exhausting, too.)
And apparently there is no option to import an Access Scope or paste-insert the list of services. (Is there?) So I get to do all of this again in production. Yay.
Actually, for my salesforce API I used access scope but for EMW I just used a separate user account per device with security groups.
Our version of EMW is like MES, the user enters their employee ID for tracking but the login is from (for example) handheld001
Thanks for documenting this Jason.
I guess I never really thought about how much work this would be if you were trying to use built in functionality and lock it down to only that.
Do you know if there is a business object for functions?
Say you want to trigger a function that uses SO business objects, do you also have to grant the user permissions to use the SO business object or can you just grant them access to the function?
votedā¦
Security groups arenāt enough, though. I can do a quantity adjustment in the app as EKWUser01 - a user that has zero rights to anything in normal client Epicor. The app is hitting the business objects, not the menu security.
But for an API integration, yes, I did the same thing of giving access scope to an API key. That works great.
Interesting thought - I would say the function is plenty, since I have an integration where the user has access scope (and the API key has the same scope) and all I gave it access to are a function library and BAQs. But in that case itās not a Function BO, itās the function itself.
Interesting thought - I would say the function is plenty, since I have an integration where the user has access scope (and the API key has the same scope) and all I gave it access to are a function library and BAQs. But in that case itās not a Function BO, itās the function itself.
Thatās what I should have saidā¦ the function itself. The only reason I ask is because this seems like a lot of work to lock down the rest API when these are native apps we are using i.e. EMW. I wish there were prebuilt access scopes for these technologies.
On the security front, I was perusing the Kinetic 2021.1 user guide for EMWW (because they donāt know the app name changedā¦) and it mentions Azure AD auth:
But the setup guide for EKW (even for Kinetic 2021.1 [and.2]) does not say anything about Azure.
Itās just an FYI. I am not really in a position to test this as yet anyway, but it would be interesting of others have done Azure with EKW.
Yeah, I got azure ad auth working with mobile CRM, but in 10.2.500 you canāt turn off the basic authentication to the rest endpoint (as far as I know). In kinetic app servers can you turn off basic authentication and require AD only?
What I mean by this is, go to your swagger API page for that app server that you are using Azure AD with and log in with basic auth on a user that isnāt SSOā¦ you will be able to get inā¦
Wait, so the fact of a user profile being used via API overides security groups?
Technically, I believe Scope overrides everything - even Security Manager.
OK, Iād like to wrap up my hijacking of this thread and move any future EKW/EMWW thoughts that I have to a new thread or ten.
Here is the access scope that I came up with (expand the triangles).
Access scope services chart
Entity Type | Service | Description |
---|---|---|
Service | ERP.BO.CountTag | CountTag Service |
Service | ERP.BO.CustShip | CustShip Service |
Service | ERP.BO.EmpBasic | EmpBasic Service |
Service | ERP.BO.InvTransfer | InvTransfer Service |
Service | ERP.BO.IRWarehseSearch | IRWarehseSearch Service |
Service | ERP.BO.IssueReturn | IssueReturn Service |
Service | ERP.BO.JobAsmSearch | JobAsmSearch Service |
Service | ERP.BO.JobEntry | JobEntry Service |
Service | ERP.BO.JobMtlSearch | JobMtlSearch Service |
Service | ERP.BO.JobOperSearch | JobOperSearch Service |
Service | ERP.BO.JobPart | JobPart Service |
Service | ERP.BO.MasterPack | MasterPack Service |
Service | ERP.BO.MaterialQueue | MaterialQueue Service |
Service | ERP.BO.MaterialQueueTranTypes | MaterialQueueTranTypes Service |
Service | ERP.BO.MiscShip | MiscShip Service |
Service | ERP.BO.Packing | Packing Service |
Service | ERP.BO.PackOutSearch | PackOutSearch Service |
Service | ERP.BO.Part | Part Service |
Service | ERP.BO.PartBinSearch | PartBinSearch Service |
Service | ERP.BO.PartPlantSearch | PartPlantSearch Service |
Service | ERP.BO.PartPlantWhseSearch | PartPlantWhseSearch Service |
Service | ERP.BO.PO | PO Service |
Service | ERP.BO.PODetailSearch | PODetailSearch Service |
Service | ERP.BO.PORelSearch | PORelSearch Service |
Service | ERP.BO.RcvDtlSearch | RcvDtlSearch Service |
Service | ERP.BO.Receipt | Receipt Service |
Service | ERP.BO.ReceiptsFromMfg | ReceiptsFromMfg Service |
Service | ERP.BO.SalesOrder | SalesOrder Service |
Service | ERP.BO.SalesOrdHedDtl | SalesOrdHedDtl Service |
Service | ERP.BO.SerialNumberSearch | SerialNumberSearch Service |
Service | ERP.BO.TransOrderReceipt | TransOrderReceipt Service |
Service | ERP.BO.TransOrderShip | TransOrderShip Service |
Service | ERP.BO.UOMSearch | UOMSearch Service |
Service | ERP.BO.UOMStkSearch | UOMStkSearch Service |
Service | ERP.BO.Warehse | Warehse Service |
Service | ERP.BO.WarehseSearch | WarehseSearch Service |
Service | ERP.BO.WhseBin | WhseBin Service |
Service | ERP.BO.WhseGroupEmpSearch | WhseGroupEmpSearch Service |
Service | ERP.Rpt.PackagingLabel | PackagingLabel Service |
Service | ERP.Rpt.RcvLabel | RcvLabel Service |
Service | ICE.BO.AccessScope | AccessScope Service |
Service | ICE.BO.AdminLicensing | AdminLicensing Service |
Service | ICE.BO.BAQDesigner | BAQDesigner Service |
Service | ICE.BO.LangTran | LangTran Service |
Service | ICE.BO.Report | Report Service |
Service | ICE.BO.SysAgent | SysAgent Service |
Service | ICE.BO.SysPrinter | SysPrinter Service |
Service | ICE.BO.UD21 | UD21 Service |
Access scope BAQ list
Entity Type | BAQ | Description |
---|---|---|
BAQ | BISC_HH_GetCustomSettingsTable | BISC_HH_GetCustomSettingsTable BAQ |
BAQ | BISC_HH_GetEmptyUDTables | BISC_HH_GetEmptyUDTables BAQ |
Some notes about these:
- Services include
ICE.BO.UD21
. THIS IS THE UD TABLE THAT I CHOSE. You can/might/will choose a different one. Change accordingly. The purpose of it is to store the company settings for your handhelds/apps. On that noteā¦ - You need to import those two BAQs from EpicCare KB0101231 (thank you @hkeric.wci for this post). Import into ordinary Epicor, I mean.
a. Donāt change the UD table name in the custom settings BAQ. Really, donāt. Really.
b. The empty UD tables BAQ is pretty handy! Import that first and it will help you pick a UD table to use. (Its real purpose is for the app menu in the Roaming settings.) - If you, like me, get the bright idea to assign the access scope to the app server BEFORE you have added anything to it
a. Donāt do that
b. At a bare minimum you need your new access scope itself to contain the service calledICE.BO.AccessScope
! Ha, Interesting things happen when you donāt do thatā¦ - Youāll need more services; I havenāt tested everything yet and I intentionally skipped some like labor (our material handlers are all indirect). And more BAQs if you get to that point. I got it running and itās time to move on.
Now to move it to Production! Here goes nothing!
@SteveFossey I wonder if I have hit 20 hours yetā¦
I remember that 20 hours post
Finally someone reads my posts Nice!!