Skip to main content
Connect Boomi to Oleria to see who can access your Boomi Enterprise Platform account and what they can do there. Oleria reads users, roles, account groups, and the audit log through the Boomi Platform API, using a Platform API token or a Boomi user’s password.

What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from Boomi:
  • Accounts - every user with a role in the account or in one of its account groups. Each account shows its roles, whether a role grants account administration (the ACCOUNT_ADMIN privilege, directly or through an inherited role), single sign-on status, and the last sign-in Oleria found in the past 12 months of the audit log.
  • Roles - Boomi’s built-in roles and your custom roles, including which built-in role a custom role inherits from, and which users hold each role.
  • Account groups - each account group and the users in it, with the roles they hold in the group.
  • Shared Web Server users - the users that call web services published on your runtimes, shown as non-human identities (service accounts), each with its API token or client certificate as a credential. Oleria never reads or stores the token value.
  • Activity - Boomi audit log events, including sign-ins, users added or removed, role changes, account group membership changes, and API token changes.

Prerequisites

  • A Boomi user, ideally dedicated to Oleria, whose role includes the API and ACCOUNT_ADMIN privileges. The built-in Administrator role has both.
  • To connect with a password instead of a Platform API token, the user must be a regular (non-SSO) user or an SSO administrator, and must not use two-factor authentication. Boomi accepts a password only from those users, and Oleria can’t send the per-call code that two-factor authentication requires. Other users need a Platform API token.
  • Optional: Runtime Management Read Access (ATOM_MANAGEMENT_READ_ONLY) to discover Shared Web Server users, and VIEW_AUDIT_LOGS for activity and last sign-in.
  • Admin access to the Oleria workspace
Boomi doesn’t offer service accounts or OAuth clients for its Platform API. Every token and password belongs to a Boomi user and carries that user’s roles, so use a dedicated user and give its role only the privileges above.

Create a Platform API token in Boomi

Skip the token steps if you connect with a password, but still find your account ID.
1

Sign in as the integration user

Sign in to the Boomi Enterprise Platform as the Boomi user that Oleria will use.
2

Open Platform API Tokens

Select Settings -> My User Settings -> Platform API Tokens.
3

Create the token

Select Add New Token, enter a name such as Oleria Integration, and select Generate Token.
4

Copy the token

Copy the token now.
Boomi shows the token only once. If you lose it, generate a new one and update the connection in Oleria.
5

Find your account ID

Select Settings -> Account Information and Setup and copy the Account ID.

Connect Boomi to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Boomi.
2

Complete the connection form

Select Continue and provide the following:
3

Confirm the connection

Select Authenticate. Oleria checks the token or password against your Boomi account before saving it. Find the connected Boomi instance on the Connected tab of your Oleria Integrations page.

Verify the integration

Confirm the Boomi instance appears on the Connected tab of your Oleria Integrations page. After the first sync completes, review the discovered accounts, roles, and account groups in your Oleria workspace.

Remediation actions

Oleria runs actions as the Boomi user the connection signs in as. Before an action runs, Oleria checks that the user’s roles grant the API and ACCOUNT_ADMIN privileges, directly or through an inherited role. Every action needs both. If the user already has, or already lacks, the access an action changes, Oleria makes no change. Oleria refuses to remove access from the Boomi user the connection uses. If Disable user accounts, Delete user or Remove user from group fails partway, the roles already removed stay removed and the action can’t be reverted. Check the user’s roles in Boomi and add them back there.

Known limitations

  • Platform API tokens aren’t discovered. Boomi’s API doesn’t list user API tokens. Token creation, renaming, disabling, and revocation still appear as audit activity.
  • Runtime installer tokens and API Management API keys aren’t discovered. Boomi’s Platform API can’t list them. Their changes still appear as audit activity.
  • No disabled or locked state. Boomi users either have access or are removed. A user Boomi locked out after failed sign-ins still shows as enabled, because the API doesn’t report locks.
  • No MFA, creation, or password change dates. Boomi’s API doesn’t expose two-factor settings or these dates, so Oleria shows them as unavailable.
  • No failed sign-ins or IP addresses. Boomi’s audit log doesn’t record failed sign-ins and has no IP address or device for any event. Boomi keeps audit entries for 12 months.
  • Environments, runtimes, folders, and processes aren’t discovered. This is an identity governance integration.
  • Account groups’ member accounts aren’t discovered. Only the users in each account group are.
  • Shared Web Server users can’t be disabled from Oleria. Boomi has no disable setting for them.
  • Adding a user to an account group isn’t supported, because Boomi requires a role for each group membership.

Contact us

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