Service Accounts - User Tie Needed?

Looking for information, documentation, and best practices regarding Service Accounts(SA) and overall Authorization for external calls and ION connection points & flows. I would like to understand more of the necessity or benefit of tying infor users to SAs? They seem to be optional, but should they required? What's best practice?...etc.. My trials appear to show you do not need to have user setup with a SA make Authorized Apps and ION work.

Case 1 - Authorized Apps - External Calls

We have web applications calling Authorized Apps (AA) to submit data to ION ~ CSD. We initially Downloaded credentials of the AA by creating a SA and associating that SA with an infor user ( a person) However, our organization does not want SAs tied to infor users. So, I tested our process using the same AA client_id and secret paired with an SA that was not setup with an infor user. This also worked successfully. The SA didn't even have any oAuth2 scope. Is this viable or best practice? Security risks? As the credentials are downloaded for the SA and used in the web application, I believe this ok. I just don't understand the need for the infor user on the SA.

Case 2 - ION Desk Connection Points & Flows

Following that same logic of a SA not tied to infor user, I wanted to give that same type of setup of a SA account to a ION Desk Connection Point for its Authorization. When I attempted to import the SA file, it gave me error saying the user was invalid. Which is true as no user name is present in the file, it was zero length "" as the SA was not set with a user. I edited the file to provide "none" for the user name and reattempted the import for the Connection Point - Authorization. The import of the file worked and I could save the Connection Point with that SA. The Connection Point worked successfully within ION by processing the Document file it was configured for. Is this workaround something anyone has used? Again, what is does a user tied to a SA really do for security here?

Steve

Find more posts tagged with

Authentication

Accepted answers

All comments

unknown

We use AA's for making ION API web service calls into our ERP applications running in Infor (i.e. CloudSuite Financials). In that case, you MUST have an SA tied to a user because you need your "real" user in order to be able to assign application security roles to that user in IFS (which ultimately become roles assigned to the "Actor" within the ERP application). The SA invokes the web service on behalf of the user/actor. Without that tie to the user, the ERP application will reject the call as not authorized because it doesn't know which roles/security classes the SA has within the ERP application, That is the use-case for assigning users to SAs, but you may not need them in all cases.

unknown

Thank you for your helpful response. A little confirming..

In our Case 1, the AA is tied to a Messaging Service (IMS). Likely an untied AA is ok (perhaps) in this case as you describe. So depending on the API call, the user may or may not be needed. From relooking at the user mgmt roles, the infor user could be given security permissions to the ERP APIs. So in your case where Finance APIs are called, a user will need that Finance role to successfully call it or the SA on its behalf. Am I following correctly?

I may have been somewhat misguided as to how an infor user(Actor) is tied/untied to any roles in the ERP. I was told that was all about the operators, which I believe is still true. But operators have nothing to with API calls, the infor user security is about the access to different infor solutions and/or API calls which may be tied to SAs when needed. Again, am I understanding correctly?

Follow-up Questions

If a user is not needed for a API call, is it still best practice to still tie a user to the SA?
- The idea here is the organization doesn't want a user name and password given out, just SA credentials for a set of non-login credentials. (i.e. lower security exposure that a person cannot log in under this "processor" user)
- I suppose it depends on the call, but don't see any additional security risk if the API doesn't need a user.
When you need a user as in your case, do you create a genetic non-person user as best practice? e.g FinanceAPIUser
How do the SAs oAuth2 scope have impact? Why would use if user security roles are used? Just an additional layer as exceptions(as in restrictions of what they have) to the user's roles?

unknown

The ERP applications that I am talking about are "Landmark"-based applications (CloudSuite Financials and CloudSuite Global HR). Those applications have a concept called "Actors", which is a user record defined within the ERP to associate an Infor user with a Landmark user. Perhaps in your ERP application, they are called "operators".

Regarding your follow-up questions. Yes, we usually create a generic account that we tie to the SA. It's both for the security reasons that you mentioned and because if we tied it to a real person and that person left the organization then the SA would become disabled.

Regarding oAuth2 scope, we don't do much with that because the security roles better control what can be done within the application.

Copyright © 2025 Infor. All rights reserved.