SSO and Epicor credentials


We’ve been working through implementing Single Sign On for about a month now and have hit a potential roadblock that surprised me a bit. Our ultimate goal is to have our Windows/AD credentials be the master credentials for as many programs as possible. We don’t want our users to have to change passwords in multiple programs as this leads to different passwords, forgotten passwords, etc. This goal led us to SSO for Epicor. We’re on

The SSO configuration went through without issue, besides an EDD mix up, but when I was testing our MES login process I found an interesting nugget. We have the User linked to the Employee record for various reasons. This will prompt the operator for a password after they clock in/enter their Employee Number. When I had the User flagged as Require SSO I was NOT able to enter my password, and received an error that I needed to use SSO. When I unchecked that checkbox I was able to proceed forward, however the password that worked was my Epicor credentials and NOT my windows credentials. We verified this by testing a user that had a different Epicor and Windows password. I also tested this against a BPM Form password prompt and found the same result here, the Epicor password is what was needed.

We will be working through the Azure AD integration later this week, but I wanted to post this to the larger group to see if anyone has been able to configure Epicor to treat the Windows credentials as the Epicor credentials (essentially a passthrough) and not require separate maintenance for each system?

1 Like

It sounds like there is something else configured wrong. We use SSO with MES and don’t get a password prompt. If you are using a shared workstation, the user that’s setup for SSO don’t link the employees to that user account.

1 Like

An easy fix would be to decouple the user from the Employee, but that’s not an option here. We need that linkage primarily for login security. Without that link it would be possible for an operator to login someone else, whether by mistake or not.

We tested the unlinking of user from employee, but during the password prompt from the BPM form the Epicor password was still what was required.

1 Like

So each “EndPoint” in Epicor can have a different authentication scheme. You have one that’s using the Epicor username/password and one using AD. In your workstation’s .sysconfig file, you choose which endpoint to use.

    <!-- Specifies the CustomBinding type; only UsernameSslChannel or Windows are allowed over HTTP  -->
    <EndpointBinding value="UsernameWindowsChannel" options="TcpBinaryUsernameSslChannel|TcpBinaryWindowsChannel|TcpBinaryUsernameWindowsChannel|HttpsBinaryWindowsChannel|HttpsBinaryUsernameChannel|HttpsOffloadBinaryUserNameChannel|HttpsBinaryAzureChannel|HttpsOffloadBinaryAzureChannel|HttpsBinaryIdpChannel|HttpsOffloadBinaryIdpChannel|HttpBinaryUsernameSslChannel|UsernameSslChannel|Windows|UsernameWindowsChannel" />

The SSO only prevents users from going back to the UsernameWindowsChannel, i.e. the Epicor Username/Password.

When you set up AZ AD then you’ll have another endpoint and will have to update the clients to use that endpoint.

1 Like

Right now we have that setting at “Windows” per the SSO config docs. Is there a different option that passes the windows credentials into Epicor? Will this come with Azure AD?

1 Like

When we have it set to Windows, there is no prompt. Epicor logs into the user associated with that Windows ID.

With AZ AD, you are prompted for your AZ AD login and then you get a token. It then uses that token while fresh or prompt again if expired. You can set Conditional Access rules in AZ AD to challenge the user for credentials or MFA if required more often.

1 Like

What happens when you’re prompted for credentials inside of a process? As in a BPM Form that is configured to prompt for a password.

1 Like

I’ve never tested that BPM forms.

I do know that working with SharePoint attachments always uses Epicor username/password and not AZ AD.

1 Like

That doesn’t work @elfrykman if you are using Azure, however you can easily mimic it with a customization.


How difficult was that customization? That looks to be calling out the O365 credentials with MFA. We wouldn’t need MFA for this yet, but that’s very intriguing. That might help bridge the gap we have if we can get it to work the way we need it.

1 Like

It was incredibly hard
I’ll share the code below and do my best to explain it but be warned it’s a tough one :yum:

first parameter boolean force auth
second parameter blank allows anyone to authenticate, if email is passed forces that user to authenticate
Last Parameter is the Form you are in
var x = Ice.Core.AzureActiveDirectory.GetAzureADToken(true,"",IP_TEST);

//x contains the new token and email address of the authenticated user if successful.



Haha, well played. To ask the dumb questions, this was added as a customization to the BPM Form to launch on the click of the custom button? Do we need Azure AD configured in any special way? We have O365 in use for all users, so this shouldn’t be a huge issue.

1 Like

Yeah exactly added as a customization on top of BPM Data Form.

No, just follow the Azure Setup in the Install Guide to setup Azure Auth and it should just work.

1 Like

We’re working our way through the Azure part now, but thought of an interesting question. Is there a way to have this code simply run when the BPM Form is launched instead of requiring the user to click a button? I’m thinking about ways to have this completely replace the places where we prompt for user credentials (MES employee clock in specifically) but need this to look as seamless as possible.

Thanks for the help, this is exciting stuff!

1 Like

Sure just move it to the Load Event portion of the BPMForm.

1 Like

Unless you are using Information Worker with Public Cloud…we had SSO all set up and working, and had to disable it when we set up Information Worker.

Or SharePoint/DocStar.

1 Like