Explanation:

User enumeration is an attack where a malicious actor tries to determine valid usernames by observing differences in application responses (e.g., "User Not Found" vs. "Invalid Password"). By returning a generic "Access Forbidden" or similar error for both non-existent users and users with insufficient permissions, Reltio helps protect user privacy and makes it much harder for attackers to compile a list of valid accounts. 

Key points regarding this practice:

• Security by Obscurity: It hides whether a user account exists at all, forcing an attacker to guess both a valid username and the correct password/credentials without confirmation of the former.

A bit more detail: 

Reltio evaluates access based on permissions/security config, not just “does this username exist somewhere.”
• When the permission configuration is present for an operation or resource, but the user (or their roles) is not present / not mapped in that config, the platform interprets that as “this principal has no rights here” rather than “this principal doesn’t exist.”
• In that case, the correct semantic HTTP response is 403 Forbidden (the caller is authenticated but not authorised), not 404/“User Not Found.”Internally, this is often summarised as:

If the permission config is present and the role/user isn’t in it, then the user simply has no access. The API therefore returns Access Forbidden rather than User Not Found. [1]

So even if the user has not been created in Reltio User Management (or hasn’t been synced/provisioned as you expect), by the time the API is processing the request, it just sees “no matching access rule,” which maps to 403 Access Forbidden.