Epicor Rest Helper (Nuget) Updated V2

Regular windows SSO cannot be easily used with Rest calls of any kind. If you are using Azure AD you can generate an Azure Token with your Azure Credentials but regular Windows SSO is not really possible with REST.

2 Likes

@jason_van_clark Are you wanting to access the API under the user context whereby permissions to the REST is determined by the user making the call? Why not just create a single Epicor API key and use that for all REST calls?

1 Like

Thanks for clarifying.

I have an API Key, but I am not sure how to do what you are suggesting. I do not have any permissions set on my BAQ but I am not sure if there are any other security settings on our epicor installation that would require user authentication.
Would I just leave the username and password variables blank when trying to use EpicorRest?

No you would either populate these or use a token instead there is no way to do ā€œWindows Authā€ with REST

1 Like

You could just setup a user specifically for the API (eg. api_user) in Epicor that isnā€™t bound to the domain or SSO and use that in your EpicorREST calls:

image

ā€¦and depending on how your app is setup, allow multiple sessions:

image

ā€¦then bind to your EpicorREST instanceā€¦

EpicorAPILibrary.AppPoolHost = XXX;
EpicorAPILibrary.AppPoolInstance = YYY;
EpicorAPILibrary.UserName = AAA;
EpicorAPILibrary.Password = BBB;
EpicorAPILibrary.CompanyID = CCC;
EpicorAPILibrary.UseWebServicesLicence = true;
EpicorAPILibrary.UseSessions = true;
EpicorRest.IgnoreCertErrors = false;

1 Like

thatā€™s a good idea but I donā€™t think my DBA is up for it. Iā€™m going to look into the Azure tokens

Jeff is describing Basic Auth. These are the authentication types allowed in REST calls (everywhere, not just Epicor):

Best practice for Basic auth is to not use it but if you do then donā€™t store the username and password but grab it from a secrets manager.

Yes, that :point_up_2: ā€¦ I did make an assumption that your app is private/internal using https, which ours is.

This may not be applicable to Epicor Rest Helper (Iā€™m not sure if RestSharp supports it) but Windows/NTLM Authentication is possible with new HttpClient(new HttpClientHandler { UseDefaultCredentials = true }).

I have written my own client library for use at our company and this is one of its authentication options.

How would this work? REST is by definition Stateless all it sends are headers so Iā€™m not sure how NTLM Authentication would work without some other middleware that generates a token or a session or something that would prove who you are.

Currently the Epicor SSO just looks at %Environment.User% and compares it to the SSO UserID setup in User File and if they match presto!

Do you have any info as to how this works for a REST call it doesnā€™t computeā€¦

Honestly I canā€™t tell you the inner workings, all I know is that Iā€™ve been using it since 2019 :slight_smile:

As long as the Epicor app server has Windows authentication as one of its bindings and your user account is set up with Domain and OSUser fields configured, it works great.

You can use NTLM auth in Postman to test it out, it works just as well.

Looks like RestSharp does support NTLM authentication, so maybe this library could make use of it.

I know Windows auth probably wonā€™t last much longer in Epicor, but itā€™s still our authentication method for the ā€˜smart clientā€™. We use Azure AD for Kinetic web.

Thanks Iā€™ll poke around Microsoft doesnā€™t recommend this approach so seems a bit dated but if its an easy implementation maybe we can add it.

1 Like

Yes, if you are running IIS with NTLM enabled, then HttpClient (which is running under the hood of RestClient) should work.

Since ERP is a valuable asset, many will segment it from the rest of the domain and provide finer access control to it. Epicor SaaS users get that automagically.

How many companies still use NTLM for Epicor authentication I wonder? :thinking:

**Edit: The authentication section I posted above was from PowerShell 7, which is cross-platform and why it will never support NTLM.

2 Likes

And this thread grows even more intriguing

NTLM is 90ā€™s authentication technology. If you want to use current Windows authentication and donā€™t have AzureAD then you would need some service to trade your Kerberos ticket for an OAuth2 token like this: https://apim.docs.wso2.com/en/3.2.0/learn/api-security/oauth2/grant-types/kerberos-oauth2-grant/

If you do have AzureAD, this would be a good time to start using it. Itā€™s much easier than setting up the aforementioned Kerberos to OAuth2 bridge. However, if you are allergic to the cloud then you do have that option.

2 Likes

And if you want to use non-Windows devices (phones and tablets using iOS or Android) then Active Directory wonā€™t work for you either.

Thereā€™s nothing wrong technically with Kerberos but AD is a perimeter-based model while OAuth/OpenId Connect allows for a Zero Trust Model.

Sorry we steered off onto this tangent. I think I was referring to NTLM when in reality Kerberos is what is being used.

If I understand this article correctlyā€¦

ā€¦ the method I am using to authenticate my HttpClient calls is using Kerberos, as that is the authentication method used by our Active Directory. If itā€™s good enough for Windows logins to authenticate against our Domain Controller, Iā€™m satisfied with using it for Epicor API calls.

As always, thanks for the input and discussion.

Stupid question time - what type of syntax is this? Certainly throwing errors in .net 6