Skip to main content
Connect Informatica Intelligent Data Management Cloud (IDMC), formerly Informatica Intelligent Cloud Services (IICS), to Oleria to see who has access to your IDMC organization and what they can do. Oleria signs in to the IDMC REST API as a dedicated non-human IDMC user. It maps users, user groups, roles, and the non-human identities listed below in one place, so you can find dormant or over-privileged access and act on it directly from Oleria.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your IDMC organization:
  • Accounts - every user, with their name, email address, user name, creation date, creator, and whether they’re enabled. Users who haven’t activated their account are shown as disabled. Oleria uses each user’s last login time for dormant account detection. Users who sign in through Security Assertion Markup Language (SAML) single sign-on are shown with single sign-on required. For users who don’t sign in through SAML, Oleria also shows the last password change if it happened in the last 90 days.
  • Non-human identities (NHIs) - each appears as its own account:
    • Non-human users - IDMC users with Identity Type set to Non-human, with their creator and last login time.
    • Secure Agents - with their runtime environment, creator, and last login in the last seven days.
    • System for Cross-domain Identity Management (SCIM) tokens - with their status and expiration date. SCIM tokens are marked as administrators, because they can create, deactivate, and regroup users.
    • Elastic runtime image tokens - with their expiration date and the user who created them.
    Each token also appears as a credential. Oleria doesn’t import token values.
  • User groups - every user group and its members. Groups whose names match a group in your SAML group mapping are labeled as synced from your identity provider.
  • Roles - every system and custom role, including roles nobody holds yet. The privileges a role grants appear on each of its assignments to a user or user group.
  • Administrator standing - users who hold the system Admin role, or a custom role with Administrator-service privileges beyond read, directly or through a group, are marked as administrators.
  • Parent organization administrators - on a sub-organization, a group named Parent organization administrators (synthesized) that holds the Admin role. Parent organization administrators can switch into a sub-organization, but its API doesn’t list them.
  • Organization settings - the password policy, whether the organization has SAML users, and whether a JSON Web Token (JWT) identity provider is registered.
  • Activity - events from two IDMC logs. Oleria attributes each event to the user who performed it when it can match the user name, and Secure Agent logins to the Secure Agent:
    • The security log, up to 400 days back: logins, logouts, multi-factor authentication (MFA) events, Admin role assignments, password changes, and changes to users, groups, roles, organization settings, and SAML configuration.
    • The audit log, up to 90 days back: asset and permission changes, Secure Agent and connection changes, and other administrative events.
Oleria refreshes this data on its regular sync schedule.
Oleria doesn’t import projects, mappings, connections, or other IDMC assets, or the permissions on them. Audit log events about changes to them still appear as activity. This integration covers identity and access governance for users, groups, roles, and non-human identities only.

​
Prerequisites

  • An IDMC administrator who can create a user and a role.
  • A dedicated native IDMC user for Oleria, with Identity Type set to Non-human. A non-human user can only call the API and doesn’t use MFA, so Oleria can sign in without a person. Oleria acts with this user’s IDMC permissions.
  • A role for that user: a custom role with the privileges in the Create a role for Oleria step of Create a non-human IDMC user and role, or the system Admin role, which syncs everything Oleria can read (see Known limitations). The role also decides which actions Oleria offers. See Remediation actions.
  • Admin access to the Oleria workspace.
Use a dedicated non-human user for Oleria instead of a named person’s account. If that user is disabled or deleted, or its password changes, syncs and actions stop working. An outdated password can also lock the user out. See Troubleshooting.

​
Create a non-human IDMC user and role

The exact location and names of these settings can change over time. If the steps below don’t match what you see, refer to Informatica’s IDMC Administrator documentation on users, roles, and Trusted IP Ranges.
1

Create a role for Oleria

Sign in to IDMC as an administrator, open Administrator, and go to User Roles > Add Role. Create a custom role for Oleria with these privileges:Informatica’s documentation says that reading the security log requires an administrator role. To read the security log and run every remediation action, use the system Admin role in the next step instead, as described in Remediation actions.
2

Create the non-human user

Under Users, select Add User. Use an email address your team can receive, for example a shared mailbox. Set Authentication to Native and Identity Type to Non-human, and enter a User Name such as oleria-integration. Set Max Login Attempts higher than the default of 3, for example 10. See Troubleshooting for why. Leave Force password reset on next login cleared, since a pending reset may make Oleria’s login fail. Assign the role from the previous step, and the Elastic RTE Manager role if you chose it for Elastic runtime image tokens, then save.IDMC emails a Confirm Account link. Open it within 24 hours and set the password you’ll enter in Oleria. If the email doesn’t arrive, confirm the user’s email address under Users, then have an IDMC administrator reset the user’s password so IDMC sends a new link.
3

Allow Oleria's IP addresses (if needed)

If your organization uses Trusted IP Ranges, add Oleria’s IP addresses, or IDMC refuses Oleria’s login. Contact support@oleria.com for the current list.

​
Connect Informatica to Oleria

1

Find Informatica in Oleria

Go to your Oleria workspace, select Integrations, select the Available tab, and search for Informatica.
2

Complete the connection form

Select Connect and provide the following:
3

Confirm the connection

Select Authenticate. Oleria signs in to IDMC, checks that the connection’s user can read users, user groups, roles, and the organization, and signs out before it saves anything. Find the newly connected organization on the Connected tab of your Oleria Integrations page.
Authenticate doesn’t check whether the connection’s user can read the privileges each role grants, Secure Agents, SCIM tokens, Elastic runtime image tokens, the security log, or the audit log, or whether it can run actions. Confirm the data after the first sync, as described in Verify the integration.

​
Choose your login region

The login region is the first part of the address where you sign in to IDMC. For example, if you sign in at https://dm-us.informaticacloud.com, select North America, AWS (dm-us). If you sign in at https://dm-em.informaticacloud.com, select Europe, Dublin (dm-em). After you sign in, IDMC can move you to a different address, such as usw3.dm-us.informaticacloud.com. Use the address you sign in at, not that one.

​
Sub-organizations

Each IDMC sub-organization has its own users, and the API can’t switch between organizations. Connect each sub-organization as its own integration, with its own non-human user. If you also connect the parent organization, Oleria shows its administrators directly.

​
Verify the integration

Confirm the IDMC organization appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users, user groups, roles, non-human identities, and activity appear in your Oleria workspace. With a custom role, every sync completes with partial data, because only the Admin role can read the security log. For other partial data, see Troubleshooting.

​
Edit the connection

When you edit the integration, you can change Instance name, Login region, User name, and Password. Leave a field blank to keep its stored value. Every Update signs in to IDMC to validate the connection, with the new password if you entered one or the stored password if not, and checks that it reaches the same IDMC organization. Oleria saves a new password only after that check passes. If the stored password is outdated, the Update fails and counts as a failed login. To connect a different organization, add a new integration.
If you change the non-human user’s password in IDMC, update it in Oleria right away. Until you do, every sync and action fails and counts as a failed login. See Troubleshooting.

​
Remediation actions

Oleria can take these actions in IDMC. Before it offers them, Oleria checks that the connection’s user holds the system Admin role, or a custom role with an Administrator-service privilege beyond read, such as Organization - Update. A custom role can pass this check without the IDMC privileges an action needs, and that action then fails with a permission error. To run every action, assign the system Admin role to the connection’s user. Not yet means the Oleria app doesn’t show a Revert button for that action yet, so make the change back in IDMC. The app shows Revert on Remove user from group only while the action is within the revert window shown on it, and only if the action completed or partially completed. It also shows Revert on the two token revokes, but reverting them always fails, because a revoked token can’t be restored.
Deleting a user is permanent and can’t be reverted. IDMC has no API to disable a user, so deleting is the only way Oleria can remove a user’s access. Deleting a user doesn’t revoke Elastic runtime image tokens the user created, and doesn’t reassign assets, schedules, or connections the user owns. If IDMC refuses the deletion, for example because the user owns objects, Oleria reports IDMC’s reason. The action’s output records the user’s user name, first and last name, email address, identity type, authentication, and direct roles and groups, so you can re-create the user’s access in IDMC if you need to. Create user creates only native, human users, so re-create a SAML or non-human user in IDMC.
Revoking a SCIM token or an Elastic runtime image token is permanent. Anything that uses the token, such as your identity provider’s SCIM provisioning, stops working. Confirm the token isn’t in use before you run the action, and generate a new token in IDMC if you need one.
Delete user deletes an existing IDMC user. Create user creates a native, human IDMC user. Give the user at least one user group or role. Oleria never picks one for you. Oleria doesn’t send a password. IDMC should email the user an activation link to set their own. Create group creates a user group that grants at least one role you choose. Keep these limits in mind when you use these actions:
  • Oleria reads the target before it changes anything, makes no change if it’s already in the requested state, and reads it again afterward to confirm the change. If the target no longer exists, for example a user someone already deleted or a token IDMC no longer lists, the action fails instead of succeeding without a change. Revoking a token that has already expired succeeds without a change. A SCIM token that IDMC still lists as revoked or disabled isn’t treated as revoked: Oleria sends the revoke again, and the action succeeds once IDMC no longer lists the token.
  • Oleria refuses to create a user or group whose name already exists, or to grant a role that’s disabled because its license expired, including when it reverts a removal.
  • Oleria won’t change the roles or groups of the connection’s user, or delete it, because that could disconnect the integration or widen its own access.
  • Oleria won’t remove the Admin role, or a group that grants it, from the last active human Admin holder, or delete that user. Only users whose IDMC state is Active or Enabled count as holders. The connection’s user, non-human users, and users who are disabled, haven’t activated their account, or have no reported state don’t. If another change removes the other holder while Oleria removes the Admin role or a group that grants it, Oleria adds the role or group back and reports a failure. This doesn’t apply to Delete user, which can’t be undone.
  • Oleria won’t remove a user’s last role if the user isn’t in any group, or their last group if the user has no direct role. IDMC may not allow a user with neither, so Oleria refuses the change.
  • Remove user from role removes direct assignments only. If the user holds the role only through a user group, remove them from that group instead. If the user holds the role both directly and through a user group, Oleria removes the direct assignment and warns that the user still holds the role through the group.
  • If IDMC answers Create user or Create group with an error but the user or group exists afterward, Oleria records it as created, with a warning.
  • Reverting an action undoes only the change that action made.
If your organization maps SAML groups to IDMC roles, your identity provider manages SAML users’ assignments, so Oleria refuses Add and Remove user from role and Add and Remove user from group for SAML users. Make those changes in your identity provider. Changes for native users, Create user, and Create group still run. If Oleria can’t read the SAML group mapping, a SAML user’s change runs with a warning that your identity provider may undo it.
Oleria refuses Delete user for any SAML user, whether or not your organization maps SAML groups, when it finds a SCIM token that isn’t expired, revoked, or disabled, because your identity provider could provision the user again. Oleria may not find every SCIM token (see Known limitations), so if your identity provider provisions users through SCIM, remove the user’s access in your identity provider instead of deleting them here. When Oleria finds no such token, it deletes the SAML user with a warning that IDMC may create the user again at their next single sign-on if your identity provider still grants them access. If Oleria can’t read the SCIM tokens, the deletion runs with a warning that your identity provider may provision the user again.
Oleria can’t disable or enable users, because IDMC has no disable or enable API. It can’t disable non-human users or Secure Agents, revoke a user’s sessions, or change the roles a user group grants.

​
Existing SCIM connections

Earlier Informatica connections in Oleria used a SCIM base URL and token. These connections keep syncing users, groups, and group memberships in a read-only mode, without roles, activity, non-human identities, or remediation actions. The SCIM-based actions (enable, disable, and create users, create groups, and change group membership) don’t run on these connections. Upgrade to use the native actions above. Enabling and disabling users isn’t available natively. To upgrade, create the non-human user and role from Create a non-human IDMC user and role. Then edit the integration in Oleria, enter all three of Login region, User name, and Password, and select Update. Saving switches the connection to the native integration, which no longer uses the SCIM token. Use a non-human user in the same IDMC organization the SCIM connection synced. Oleria can’t check that on upgrade, because the SCIM connection didn’t record its organization. After you upgrade, don’t add the same organization again as a new integration: Oleria can’t detect that it’s already connected. After you upgrade, users, groups, and the IDMC organization itself can appear as new records in Oleria, because the native integration identifies them differently from the SCIM connection. The SCIM token stays valid in IDMC until it expires. If only Oleria used it, revoke it in IDMC.
IDMC SCIM tokens expire. When an existing connection’s SCIM token expires, the connection stops syncing until you upgrade it.

​
Known limitations

  • No MFA status. IDMC doesn’t expose MFA settings or enrollment through its API, so Oleria reports MFA as unavailable, not as disabled.
  • Last password change covers 90 days. Oleria reads password changes from the security log for users who don’t sign in through SAML. If a user’s last change is older than 90 days, or the connection’s user can’t read the security log, the date is blank.
  • Secure Agent last activity covers seven days. If a Secure Agent hasn’t logged in during the last seven days, or Oleria couldn’t read all of a day’s security log, its last activity is blank.
  • SCIM tokens may be limited to the connection’s user. IDMC may list only the SCIM tokens the connection’s user created. SCIM tokens other administrators created might not appear.
  • No IP addresses in activity. Neither IDMC log includes the IP address of an event.
  • Few failed logins. Only failed MFA verifications appear as failed logins.
  • Non-human users depend on Identity Type. If IDMC doesn’t return a user’s Identity Type, Oleria shows the user as a human account.
  • No AI agents. IDMC’s API doesn’t list AI agents. Secure Agents are runtime hosts, not AI agents.

​
Troubleshooting

  • The login is refused. Check the user name, password, and login region. The connection’s user must be a native IDMC user, not a SAML user. Use a non-human user, as described in Prerequisites: if your organization requires MFA, a human user’s login can ask for it, and an API login can’t complete MFA. If your organization uses Trusted IP Ranges, they must include Oleria’s IP addresses.
  • The connection’s user is locked out. After IDMC refuses a login, Oleria waits before it tries again. A wrong or outdated password can still cause up to three failed logins per sync, plus one for each action and each Authenticate or Update. These add up across syncs and count toward the user’s Max Login Attempts, which defaults to 3. Raise it as described in the Create the non-human user step of Create a non-human IDMC user and role, and update the password in Oleria promptly. If IDMC locks the user, unlock it in IDMC, then edit the connection.
  • Authenticate names a missing privilege. Add the privilege named in the error to the connection’s user’s role.
  • Syncs fail after Authenticate succeeded. The connection’s user may be missing Privilege - Read. Add it to the role.
  • Syncs complete with partial data. The connection’s user can’t read the security log, the audit log, Secure Agents, SCIM tokens, or Elastic runtime image tokens. Oleria skips what it can’t read and syncs everything else. Only the system Admin role can read the security log, so with a custom role every sync completes with partial data, and last password change and Secure Agent last activity stay blank. For the rest, add the privileges from the Create a role for Oleria step of Create a non-human IDMC user and role. After you fix the role, Oleria doesn’t go back for log events from the time it couldn’t read them.
  • Secure Agents, SCIM tokens, or Elastic runtime image tokens are missing without partial data. Your organization doesn’t use that IDMC feature, so there’s nothing to import. Some SCIM tokens can also be missing for another reason. See Known limitations.
  • An action isn’t available or fails with a permission error. The connection’s user’s role doesn’t allow it. See Remediation actions for the role actions need.
  • IDMC session settings. Oleria works with both IDMC session IDs and JWT sessions. It signs in again before a session expires, or sooner if IDMC rejects the session, so you don’t need to change your session settings.

​
Contact us

For questions about this integration, contact us at support@oleria.com.