> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Akamai

> Connect your Akamai account to Oleria to continuously discover Control Center users, the roles they hold on each group, API clients and their credentials, and Event Viewer activity.

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](https://techdocs.akamai.com/iam-api/reference/api) and [Event Viewer API](https://techdocs.akamai.com/event-viewer/reference/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](/integrations/overview.md#sync-model).

## 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

> [!NOTE]
>
> 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](https://techdocs.akamai.com/developer/docs/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](#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.

> [!WARNING]
>
> 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:

| API service | Access level | What it adds |
| :- | :- | :- |
| **Identity Management: User Administration** (required) | **READ-ONLY** | Users, their roles on each group, the role catalog, groups, and the password policy. |
| **API Clients Administration** (required) | **READ-ONLY** | API clients, their credentials, API services, group roles, and owners. |
| **Event Viewer APIs** | **READ-ONLY** | Activity. Without it, Oleria syncs everything else and shows no activity. |

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:

| API service | Access level | What it allows |
| :- | :- | :- |
| **Identity Management: User Administration** | **READ-WRITE** or **ADMIN** | Locking, unlocking, creating, and deleting users, and adding and removing their roles on groups. |
| **API Clients Administration** | **READ-WRITE** or **ADMIN** | Locking and unlocking API clients. |

## 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:

| Field | Notes |
| :- | :- |
| Host | The `host` line, such as `akab-xxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxx.luna.akamaiapis.net`. You can include or leave out `https://`. Oleria accepts only hosts under `luna.akamaiapis.net`. |
| Client token | The `client_token` line. |
| Client secret | The `client_secret` line. |
| Access token | The `access_token` line. |
| Account switch key (optional) | Only for a multi-account (partner) API client: the switch key of the Akamai account to connect. Leave it empty otherwise. |

**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.

> [!NOTE]
>
> 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.

| Action | What it does | Reversible? |
| :- | :- | :- |
| Disable user accounts | Locks the user, so they can't access Control Center. This is the recommended way to remove a leaver's access: unlike deleting, it keeps the user's roles and history and can be undone. If the user is already locked, Oleria leaves them as is. | Yes - unlocks the user, if they're still locked. |
| Enable user accounts | Unlocks the user. If the user isn't locked, Oleria leaves them as is. | Yes - locks the user again, if they're still unlocked. |
| Create user | Creates a Control Center user with the email address, name, and roles on groups you choose. Akamai requires at least one role on a group, and allows one role per group. Akamai emails the new user a one-time password. Oleria sets the user's second factor to Akamai MFA (or two-factor authentication if your account doesn't accept MFA) and their country to that of the user the connection acts as, or to the United States if that user's country isn't available. If a user with that email already exists and already holds every role you chose, Oleria leaves it as is. If any of those roles is missing, the action fails and doesn't change the user; use **Add user to role** to grant them. | Yes - deletes the created user. |
| Delete user | Deletes the user from the account. | Partly - creates the user again with the same email, name, country, second factor (or two-factor authentication if your account doesn't accept MFA), roles on groups, time zone, language, and job title, and Akamai emails the user an activation link. Akamai gives the user a new ID, and they must activate the account from that email; their old password and history aren't restored. If a user with that email already exists, Oleria leaves it as is. |
| Add user to role | Gives the user a role on a group. A user holds one role per group, so this replaces any role they had there. If the user already holds the role on that group, directly or through a parent group, Oleria leaves it as is. | Yes - restores the previous role on the group, or removes the grant if there wasn't one. |
| Remove user from role | Removes the role the user holds directly on a group. On a subgroup, the user goes back to the role they get from the parent group. | Yes - puts the role back on the group. |
| Disable NHI accounts | Locks an API client, so it can't make requests. If the client is already locked, Oleria leaves it as is. | Yes - unlocks the client, if it's still locked. |

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](#create-the-api-client). 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](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.