REST API authorization

We have an IIS server running a EPICOR ERP system. The ERP system installs IIS application pool, which certain urls are remapped to be handled by the app pool.

Here is what it says about the verification:

For security reasons you should always use https with REST API

REST API supports 2 authentication methods Basic authentication The
username and password are combined into a string separated by a colon
and encoded using Base64. The result is placed into Authorization
header: Authorization: Basic {encoded string} Token authentication The
bearer token can be obtained for the user from token service. See
https://epicorapp2/ERP10.1Test/TokenResource.svc/help (Token
authentication should be enabled). Then access token should be send in
the Authorization header in the following form: Authorization: Bearer

The IIS server itself has anonymous authentication for the top level url (and all others are turned off).

My experience in Chrome when I go to the desired URL:

https://epicorapp2/ERP10.1Test/api/help/

is that one gets a pop-up asking for username/password (where the user/passord is for the ERP system, not for the host IIS system).

But I am unable to duplicate this experience either with Postman or Insomnia
(I have tried putting in the username/password in the authorization options for both Postman and Insomnia. I get a 401 authorization error.

Any ideas?

that popup is browser-specific behavior, when it receives WWW-authenticate header from server.
Postman does not show it.
In Postman you should select Basic Auth as Authorization type.

Thanks for the quick reply.

As indicated in the original post. I have set username/password and select BasicAuth and I can see that being sent as token in the outbond header (in both Postman and Insomnia) and yet I still get a 401 auth error on the reply.

(For chrome, I was just indicated that manual entry username/pass works fine in the popup)., so I know the app pool service is working properly.

And by token in Authorization header you mean “Basic <name:pwd-encoded in Base64>” ?

Yes, exactly that.

It should work then…
Try different URL, like service list in /api/v1/
Try other user/password.

Are you trying to hit the help URL with postman? If so…why ?

I have tried multiple URLS (e.g. https://epicorapp2/ERP10.1Test/api/v1/Erp.BO.JobEntrySvc/JobEntries?%24top=1) as well as https://epicorapp2/ERP10.1Test/api/v1 and api/help. It is not a URL issue. (all work manually via chrome and the edge/chromium dev browser I have.

It is not username/password (I can try multiple of those, same luck. only works manual with the browser not postman).

I have also tried NTLM, Basic and NoAuth

What is a potential (but puzzling) clue Is that I bring up Fiddler (which asks as a local proxy to outbound http requests, and use the Rules/Automatically Authenticate) then both Postman and Insomnia work, and I spy on the traffic going both ways in Fiddler.

This last test works with BasicAuth, but not NoAuth (no surprise there)

Can this be an issue with how the IIS is configured (we will be moving from Epicor 10.1.500 to 10.2.400 on May 18th) but we cannot move earlier. (yea, I know beta software, but I have given our deadlines I have to start hacking with JobEntryService today to try and figure out what the 11 custom methods that our traces show a basic JobEntry do).

I should mention an additional glitch that I should have fixed next week. I am using a self-signed cert on the IIS 8.5 server (I am forced to wait till next week when I.T. can get a true certificate from DigiCert).

Certificate error usually looks differently, not like 401. It either cannot reach, or writes something about SSL error.
Basic auth worked from the very beginning of REST, in 10.1.500, so version is not an issue.
For IIS settings check Authentication section, verify that only Anonymous is enabled there.

Do you use Single Sign On?

@hmwillett and I saw something similar when we used an APP Server with SSO, it really hated it. So we deployed another Instance without SSO, specifically reserved for API Calls etc, to keep the web.config’s seperate etc… that seemed to do the trick.

We also had the same issue via Postman.

It hated SSO, so we used another App Instanced without SSO. Maybe @Olga has seen this as well and maybe there is a secret setting somewhere for it to “ignore” SSO during API Calls.

Secret setting is to switch off Windows Authentication is IIS :slight_smile:
But in case with SSO browser login usually does not work either

So in order to accept only the Token or Epicor Credentials, its best to just deploy a second App Server (Instance) and just use that? :slight_smile: Worked for us, didnt know if others are doing something else. (For those who want to keep SSO)

1 Like

Re IIS:

Only anonymous is enabled, same for all : train,test, pilot etc.

Only one app server.

Very strange. Maybe some proxy or network settings?

You can deploy second instance for sure. But why then you need Windows Auth in the first instance if you don’t want to use it in REST? Just don’t turn it on. WCF client works with SSO with only Anonymous setting in IIS.

I am not following the SSO (Single Sign On) part of the discussion. Probably lack of familiarity with working with that (I prefer to be a developer, than sysAdmin). Is there a SSO setup config for EPICOR, or are you referring to something in IIS? or are we talking about the NT LAN domain level (we all use something similar to the DOD CAC card system to log into our computers).

Well, in any case I wanted to report back to the group;.

DigiCert PFX certificate arrived. Installed it in IIS 8.5 (Epicor 10.1.500, and we will be at 10.2.400 in about two weeks).

No problems with Swagger either with Google Chrome, or the new Microsoft Edge Chromium (in fact I recommend it for large Swagger stuff like JobEntry, which is takes 15 minutes to load the custom methods and then is broken in Chrome, Better in Chromium Edge).

Postman is still broken (can only get there via a fiddler instance in the middle).

However Insomnia is working great. which is good enough for what we do.

1 Like

SSO implies that you dont actually sign in to Epicor (it is done automagically with your windows account). So if the instance you are connecting to requires user\pass to get into Epicor, you can disregard.

2 Likes