I’m trying to create an API endpoint on a web server which calls the Epicor API as a specific user, without consuming a license (other than using a webservice license for the duration of the call) and without violating other system constraints such as a user only being allowed to be logged in from one location.
To do this I have granted the webservice user impersonation rights. In the REST API documentation I see that I need to include a header indicating the user being impersonated, for instance to act as user “Epicor” I would include this header:
OnBehalfOfToken: {“Username”:“Epicor”}
But it’s not clear to me how to make sure that the request itself is authenticated. For instance, the web app talking to the web server could ask the user for their Epicor user name and password. But the impersonation doesn’t require a password, so the user could provide the wrong password and it would still work. My server doesn’t know the user’s password so it can’t check it. I don’t want to try to (e.g.) get a token for the user from Epicor to check their password because as previously mentioned I don’t want to hold any extra resources such as licenses even if only temporarily. Is there some API that I can call to check if the user supplied user name and password are correct without allocating any resources such as session or token? Or is there some other better approach that I should be taking?
Suppose user “john” is using the web app. He clicks a button to bring up some sales numbers. This calls an endpoint on the web server which calls the Epicor API (as well as other stuff) which it then returns to John’s browser. Let’s suppose the “john” has permission to access this data in Epicor. But how does the web server know that “john” isn’t really somebody else who doesn’t have permission? The web page could ask for John’s Epicor password, but since the back end is using “webservice” to impersonate “john” we can’t give Epicor John’s password to make sure it’s really him. If we actually pass John’s user name and password instead of “webservice” then it seems to defeat the main purpose of having webservice licenses in the first place.
If all user’s of the system are using a valid Epicor username and password there’s no need to do impersonation.
Just pass those credentials along and make the web service call. For RESTFUL webservice calls without a Session the license consumption only lasts the length of the call so it shouldn’t be an issue with licensing.
I don’t quite understand what the benefit is of using the impersonation header if every user of the system will be a valid EPicor user already.
Will there be an issue if the user is already logged in (e.g. via the Epicor client) and their account is configured to only allow them to be logged in from one place at a time? Or does an API call circumvent that restriction?
We don’t want them to log in from multiple places, as we found that some users would wind up logging in from multiple places (forgetting they were logged in elsewhere I guess) and this would exhaust our licenses. Then we would have to waste time finding users and asking them to log out of the session(s) they weren’t using, or else risk losing their data by killing their sessions. Limiting them to a single login solves this problem because when they try to log in it fails, telling them they are already logged in. So they have to then go and log out in the other location before they can log in.
So this is the benefit that impersonation would give us, in that we could retain this limitation on them being logged in at most one location, but also allow API requests to be made by them. But it brings up the new problem that we don’t know how to make sure they are who they say they are.
You could test to see if it works without issue since you aren’t creating a session maybe it won’t sto you.
That failing you can do the authentication / verification yourself. Have them submit their username and password and verify it against Epicor return to them a token using JWT that tells you who they are and then use that JWT to “impersonate”
That sounds a lot like working around Epicor’s licensing restrictions, which they would certainly frown on, when you really need to purchase some more licenses and or adjust your timeout settings.