User Impersonation is readily possible in Service Accounts

The Infor OS Platform is accessed and modified by multiple independent entities—Infor Services teams, customer IT staff, and external contractors—making strong credential management and authorization controls essential. Each party may use different identity providers and privilege models, requiring consistent enforcement across heterogeneous authentication sources.

Additionally, third‑party systems frequently integrate with Infor applications using their own authentication mechanisms (e.g., OAuth2 clients, service accounts, API tokens). In these scenarios, identity propagation and action traceability are critical to determine which actor or system performed an operation, under what authority, and with what level of access.

However The current process for Authorized apps allows IONAPI-Administrators and other Administrator to download Service account credentials on behalf of other users. Moreover, the Users MAY NOT be informed that such Service Account is created on their behalf.

I believe this was originally meant for Administrator to create Service Account on behalf of a Service User which is NOT meant to be an actual user as its used to connect to other systems such as Git and other applications. However the current paradigm allows Administrator to impersonate any other User. Infor OS will be taking steps to ensure that when such credentials are created they will be notified.

However I dont think this should be possible AT ALL even by an Administrator. Specially in the case of AI these credentials can be abused without knowledge of Either Administrator or the users on behalf of whom the credentials have been created.

Note that service accounts are LONG TERM credentials and NOT tokens. As a User of Infor OS I am not comfortable with working with a system where an Administrator CAN create LONG TERM credentials on my behalf and hand it over to anyone. Moreover since different Clients APIs can work with API suites, IONAPI-Administrator role may not be protected and that allows different parties to create credentials on behalf of other entities.

Find more posts tagged with

Authentication

Admin

API

Comments

cleverly

I can't speak to what Infor's original design or thinking was, but I agree with what you've said.

You should be equally as careful and judicious in who you assign the IONAPI-Administrators role as you would be, say, the Infor-SystemAdministrator role. (As well as UserAdmin, or anyone with SCIM access, among others, since with any one of these roles you can get to all the others…)

The current process for Authorized apps allows IONAPI-Administrators and other Administrator to download Service account credentials on behalf of other users. Moreover, the Users MAY NOT be informed that such Service Account is created on their behalf.

I would change MAY NOT to WILL NOT or ARE NOT. AFAICT, there is no mechanism whatsoever to even allow the possibility that they might be notified…

Abhijit Oka

Yes, I have put MAY NOT because that is the only thing IFS team has intimated that they would do:

IFS will create a notification through the notification center, as well as send the user an email when they are associated to a service account. We will add a flag and visibility to the end user.

However, notification is NOT a guardrail, and neither are system logs and it doesnt STOP the misuse.

Abhijit Oka

I discovered there was a Snowflake incident which has similar characteristics as we have here

https://cloudsecurityalliance.org/blog/2025/05/07/unpacking-the-2024-snowflake-data-breach

https://pushsecurity.com/blog/snowflake-retro/

These breaches were driven by stolen, long‑lived credentials that remained valid for years, not by a novel exploit, albeit by malware. Once attackers had those credentials, they accessed data at scal
Snowflake’s affected customers had credentials reused from non‑approved locations (endpoints, scripts, tools compromised by infostealers), showing how easily downloadable secrets escape proper key management.

The current casewith actual Users I believe is more SEVERE than the mentioned above

Snowflake attackers primarily abused compromised service/database users—our currentpattern can expose or enable long‑lived credentials bound to real human identitiesThat makes the impact more severe: misuse is attributed to a specific person,undermining non‑repudiation, investigations, andprivacy/accountability obligation. Its not credential theft but an identitytheft.
Service users can be cleanly identified, rotated, or fully replaced, but real human users are NOT be“rotated” or replaced in the same way: Once the identity of a user is createdit is permanent and therefore credentials created on behalf of that user arealso permanent and unless the user explicitly deletes those credentials whichthe user may NOT be aware.

Copyright © 2025 Infor. All rights reserved.