Skip to main content
Akamai Control Center is where your teams manage Akamai’s content delivery, security, and DNS services. Connect your Akamai account to Oleria to see every Control Center user, the role each user holds on each group, and the API clients that can call Akamai’s APIs for the account. Oleria reads this data from Akamai’s Identity and Access Management API and Event Viewer API with an EdgeGrid API client, so you can find dormant or over-privileged access and act on it directly from Oleria. Oleria reads access to the Akamai account itself. It doesn’t import properties, CP codes, edge hostnames, or other Control Center configuration.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Akamai account:
  • Accounts - every Control Center user the API client can see, with their name, email address, username, job title, status (active or locked), and last login. Oleria also shows each user’s enforced second factor (Akamai MFA or two-factor authentication) and whether it’s enrolled, and the date of the user’s last password change, worked out from the user’s password expiry date and your account’s password rotation period. Single sign-on (SSO) status shows as unavailable, because Akamai’s API doesn’t report it. A user is marked as an admin when they hold a role that includes IDM: Users - Admin Access on a top-level group or at account level.
  • Non-human identities - every API client the connection can see, including the one Oleria connects with. Each one shows whether it’s locked, when it was created, the API services it can call and their access levels, and the roles it holds on each group. Every credential of the client is shown with its status (active, disabled, expired, or revoked), created date, and expiry date. The user who created the client is marked as its owner, except for a client that acts for another user, where that authorized user is marked as its owner instead. For a service account client, its authorized users are marked as its managers.
  • Roles - every role in the account, standard and custom, with the Akamai granted roles (permissions) each one combines. Akamai gives a user one role per group, so each assignment appears as a role on that group, such as Admin @ Top group > Web. Each assignment lists the group it was granted on and every subgroup it reaches, leaving out subgroups the user is blocked on and subgroups where the user has a different role. Account-level roles appear the same way.
  • Activity - Control Center events from Event Viewer for the last 90 days, such as logins and configuration and user administration changes. Logins are shown as logins. Other events are shown with Akamai’s event type and name. Events that someone performed while impersonating a user are flagged.
Oleria refreshes this data on its regular sync schedule.

​
Prerequisites

  • An Akamai account with access to Control Center.
  • A Control Center user who can create API clients and has an admin role on the top-level group of every contract. Akamai can hide users and data from an admin whose role covers only some groups, so a role on a subgroup can give Oleria an incomplete view.
  • The Identity Management: User Administration and API Clients Administration API services available to your account. To read activity, the Event Viewer APIs service too, and permission to use Event Viewer.
  • Admin access on the Oleria platform to add a new integration.
Akamai’s administration APIs authenticate only with EdgeGrid API clients, so EdgeGrid is the only connection method. Each Oleria integration covers one Akamai account.

​
Create the API client

The exact location of these settings can change over time. If the steps below don’t match what you see, refer to Akamai’s Set up authentication credentials documentation.
1

Open Identity & access

Sign in to Akamai Control Center as the admin described above. Go to ☰ > Account Admin > Identity & access, and under Users and API clients select Create API client.
2

Choose Advanced

Select Advanced, so you can pick exactly which API services and groups the client gets. Name the client Oleria.
3

Grant group access

Give the client access to the top-level group of every contract, with a role that can view users, roles, and API clients. Admin works, but it’s broader than Oleria needs to sync. To let Oleria take remediation actions, the role needs admin access to the groups of the users you act on.
4

Select the API services

Under APIs, select only the services in the first table below. To let Oleria take remediation actions, use the access levels in the second table instead.
5

Create the client and download the credentials

Select Create API client, then Download the credentials. The file, usually named .edgerc, holds the host, client_token, client_secret, and access_token values you enter in Oleria.
Treat the client secret and access token like a password. Anyone who has them can call Akamai’s APIs with the client’s access. Store them securely and rotate them per your organization’s security policy.
API services, for discovery: If Control Center offers ADMIN instead of READ-ONLY for a service, choose ADMIN. It covers read access. API services, only if you want Oleria to take remediation actions:

​
Connect Akamai to Oleria

1

Open the integration

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

Complete the connection form

Enter the values from the credentials file you downloaded:
3

Authenticate

Select Authenticate. Before it saves the integration, Oleria checks that the API client can list the account’s users and API clients. If the check fails, Oleria tells you whether Akamai rejected the credentials or the client is missing an API service or an admin role on the top-level groups.

​
Verify the integration

Confirm the new instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. It’s named after your Akamai account ID, in the form Akamai (account ID). After the first sync completes, you can review the discovered accounts, roles, non-human identities, and activity in your Oleria workspace.
If you rotate the API client’s credentials in Akamai, update them in Oleria by editing the integration. To keep a stored client token, client secret, or access token when you edit other settings, leave that field blank. The integration stays tied to the Akamai account it was first connected to. To connect a different account, add a new integration.

​
Remediation actions

Beyond discovery, Oleria can act on Akamai access to remediate risk. Remediation needs the access levels in the second table above. Oleria checks the API client’s API services before an action runs and reports any that are missing. If the client’s role doesn’t have admin access to every group the target user has access to, Akamai refuses the change and Oleria reports it. A few safeguards apply:
  • Oleria won’t lock or delete the user the connection’s API client acts as, or remove or replace that user’s roles, and won’t lock the connection’s own API client, because that would break the connection. If Oleria can’t tell which user or client that is, it doesn’t make the change.
  • Oleria won’t delete a user who owns an API client they created for themselves or is an authorized user of any API client, and names those clients. Transfer the clients first, or lock the user instead.
  • Locking a user doesn’t lock the API clients they own or are authorized on. Oleria lists those clients in the action’s output, so you can lock them with Disable NHI accounts.
  • Remove user from role is refused when the user holds the role only through a parent group (remove it there), when it’s a role on a top-level group and subgroups under it have roles of their own (remove those first), and when it’s the user’s last role on a top-level group, because Akamai requires every user to have at least one. Lock the user instead.
  • Add user to role is refused on a group the user is blocked on. Unblock the group in Control Center first.
  • A revert runs only while the user or client is still in the state the action left it in. If someone changed it since, Oleria leaves it as is and reports why.

​
Known limitations

  • EdgeGrid only, no OAuth. Akamai’s Identity and Access Management and Event Viewer APIs authenticate only with EdgeGrid API clients. Akamai has no OAuth flow for them.
  • Akamai groups aren’t shown as user groups. In Akamai, a group holds properties and other configuration, not people. Users don’t belong to a group; they hold a role on it. Oleria shows each group as the scope of a role assignment instead, so you won’t see Akamai groups as user groups, and the add-to-group, remove-from-group, and create-group actions aren’t available.
  • Access is shown at group level. Properties a user is blocked from inside a group, and IP allowlist conditions on the account or an API client, aren’t reflected in the access Oleria shows.
  • SSO status is unavailable. Akamai’s API doesn’t say whether a user signs in with SSO. MFA that your identity provider enforces is invisible to Akamai, so an SSO user can show Akamai MFA as not required.
  • The second factor’s type isn’t shown. Akamai reports which method is enforced and whether it’s enrolled, not which authenticator the user set up.
  • Last password change is derived. Akamai’s API doesn’t report it directly. Oleria subtracts your account’s password rotation period from the user’s password expiry date. If either is missing, the date stays empty.
  • No last-used date for API clients. Akamai doesn’t report when an API client or credential was last used. Find unused clients from their credentials’ status and expiry instead.
  • Activity is limited by Event Viewer. Event Viewer keeps 90 days of events and doesn’t return them in real time, so new events appear after a short delay. If the API client doesn’t have the Event Viewer APIs service, or its user can’t use Event Viewer, Oleria shows no activity and still syncs the rest. Events don’t include an IP address. Events by deleted users and by people outside your account, such as Akamai staff, aren’t shown, and Akamai doesn’t name the person behind an impersonated event.
  • Access from other accounts isn’t listed. Akamai partners and Akamai staff can reach your account with account switch keys from their own API clients. Akamai has no API that lists them.
  • No session revoke, password reset, or MFA reset. Oleria can’t end a user’s sessions or reset their password or second factor. It also can’t deactivate a single credential; lock the whole API client instead.
  • Visibility follows the API client’s role. Akamai can hide users and API clients from an admin whose role covers only some groups. Give the client a role on the top-level group of every contract.
  • No AI agents. Akamai has no API that lists AI agents. Tools that call Akamai’s APIs use API clients, which Oleria discovers as non-human identities.

​
Existing SCIM connections

If you connected Akamai earlier with the SCIM setup, that connection keeps syncing as before. It reads the Akamai MFA and Enterprise Application Access users, groups, nested groups, and memberships that your SCIM token covers, with the same IDs, so your access reviews keep working. The actions the SCIM setup offered - enabling and disabling users, adding and removing group members, and creating users and groups - are no longer available on a SCIM connection, so workflows that use them on Akamai fail until you switch to an API client. To get everything described on this page, edit the integration and enter the Host, Client token, Client secret, and Access token of an API client you create. The edit form shows a notice on a SCIM connection, and saving replaces the SCIM token with the API client. After you switch, Oleria reads Control Center users, which aren’t the same users as your Akamai MFA and Enterprise Application Access directory. The first sync replaces the accounts and groups from the SCIM connection with Control Center users that have new IDs, and Akamai groups appear as role scopes rather than user groups. Access reviews that are already in progress and include Akamai accounts keep pointing at the old accounts, so re-run or update them, along with any workflows that used the old accounts or groups.

​
Contact us

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