Two appserver

Thanks for the warm welcome Mark!

3 Likes

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.

image

Oohā€¦

image

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.

1 Like

oops, didnā€™t notice, and completely forgot about it from last year. Tag me if you remember to, very interested

@SteveFossey

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.

1 Like

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?

Have I ever mentioned the Epicor Ideas for making this process more friendly for DevOps? :thinking:

1 Like

votedā€¦

1 Like

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.

1 Like

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:

  1. 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ā€¦
  2. 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.)
  3. 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 called ICE.BO.AccessScope! Ha, Interesting things happen when you donā€™t do thatā€¦
  4. 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ā€¦

4 Likes

I remember that 20 hours post :smiley:

Finally someone reads my posts :smiley: Nice!!

3 Likes