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 10.2.200.22.
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?
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.
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.
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.
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?
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.
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.
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
/*
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.
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.
