Overview

You can use Identity and Access in Akamai Cloud to manage identities within an account and manage operations that those identities may perform. By authenticating identities and authorizing them to access specific services and entities, Identity and Access ensures that the right identities access the right entities. Identity and Access uses the role-based access control (RBAC) model to authorize operations on entities.

🚧

Currently, Identity and Access in Akamai Cloud is natively enabled for Linodes, Cloud Firewall, Nodebalancer, Volume, Image, and VPC. To learn about the experience for non-natively enabled services, see Identity and Access for non-natively enabled services.

📘

Identity and Access for Control Center and Akamai Cloud

Identity and Access for Control Center and Identity and Access in Akamai Cloud are two different services. This documentation is for Identity and Access in Akamai Cloud. View the documentation for Identity and Access in Control Center.

Terminology

These terms will help you understand and work with Identity and Access in ​Akamai​ Cloud.

• Role-based access control (RBAC). In the RBAC model, each service has a set of fine-grained permissions that control access to a specific service API endpoint. These permissions are then combined into predefined, functional roles that can be assigned to users.

• Identity. An identity can be authenticated in Identity and Access and represents a human user.

  • User. A user is a type of identity that can be authenticated through Identity and Access. The user identity is represented by a username.
    • Emergency access account, also known as a break-glass user. A highly privileged, emergency-only account configured and maintained by the customer which is used only when standard authentication mechanisms, specifically SSO, become unavailable. It serves as the ultimate fail-safe to ensure that infrastructure can still be managed during an outage of the Identity Provider (IDP). To learn more, see Emergency access accounts.
  • Authentication methods. In Akamai cloud computing, an identity can be verified by credentials or third-party authentication or SSO. With SSO enabled, other login methods become disabled.

• Account. An account represents an entry point for users to access and manage Akamai Cloud’s settings, billing, and cloud computing services, including identities and access control. To prevent services and settings from being shared between accounts, each account has its own unique ID with which all services and settings are associated. To learn more about accounts, see Accounts.

• Single-Sign-On (SSO). Single-Sign-On (SSO) is an authentication process that allows a user to access multiple applications or systems with a single set of login credentials (usually a username and password). Once the user logs in to one trusted system, they are automatically authenticated for other connected systems with no need to log in again during a session. Akamai Cloud only supports SSO initiated by the service provider.

  • Identity provider (IDP). An identity provider is a system or service that authenticates users and provides identity information to a service provider (SP), which is the system the user wishes to access. With Akamai Cloud, which is the service provider in the SSO context, you can configure one identity provider per account.
    • External user identity. An external user identity is a unique identifier associated with the email address of a user in the identity provider system.
    • Identity provider (IDP) session. An identity provider session is a timeframe in which a user authenticated by IDP can interact with an SP with a single log in. The session timeout is configured in the IDP.
  • Service Provider (SP). A service provider is a system or a service that a user wants to access and uses the external identity provider to authenticate themself. In the case of Akamai Cloud, the service provider is Cloud Manager.
  • SAML. SAML is an XML-based framework for securely sharing identity between the identity and service providers. The SSO login in Akamai Cloud uses SAML 2.0. To learn more, read Security Assertion Markup Language (SAML) V2.0 Technical Overview and Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants.
  • SSO enforcement. To ensure the secure login across the company, you may enforce the SSO login for all or selected users of your account.
    • Excluded users. Users excluded from the SSO enforcements, for example as part of the emergency access account setup.
    • Included users. Users for whom the SSO configuration applies when the enforcement is disabled. An administrator can use this list of users to test the SSO configuration.

• Entity. An object that has a life cycle and can be managed by an authorized user within an account. For example, a specific virtual machine or firewall rule set. A user manages an entity over time by performing operations on it.

  • Entity type. A service or capability that an entity corresponds to. For example, your virtual machines have an entity type of Linode, and your firewall rule sets have an entity type of Firewall.

• Operation. Each entity in Akamai cloud computing has a defined list of operations that an identity can potentially perform on it—for example, update a Linode. Each operation is mapped to one corresponding permission.

• Permission. A permission is the most granular level of access defined by ​Akamai​. Its name derives from a corresponding Linode API operation. For example, the resize_linode permission represents the Linode’s API Resize a Linode operation.

  • Global permission and Specific permission. References to the legacy grant system. To learn more, see Migration from grants to Identity and Access.

• API (Application Programming Interface). A set of rules, definitions, and protocols that allow software applications to communicate with each other or users to interact with software. It defines how requests and responses should be structured and provides access to specific functionalities of a system. Each API typically exposes a set of endpoints that clients can interact with.
  The Linode API for Identity and Access allows users to interact with the Akamai Cloud platform and manage entities.

  • API endpoint. An API endpoint is a URL where an API receives requests from clients. Each endpoint corresponds to a unique operation on an entity and serves as the access point for interacting with the API. The API server checks if the user has the appropriate permission to invoke the API, and if so, processes the request at the endpoint and returns a response.

• Role. A role is a collection of permissions. It represents a function that a user has in a business organization. The role enables the necessary access to perform the allowed operations on the corresponding entities satisfying the function that the user or system has.
  There are two types of roles:

  • Account access roles. These roles give access to:

    • Account level operations, such as account settings, service transfers, billing, and payment. An example of such a role is account_billing_admin.
    • Create new entities. An example of such a role is account_firewall_creator, which enables you to create new firewalls.

  In Linode API for Identity and Access, you’ll see these roles as account_access. In the list of roles on the user interface (UI), in the Roles tab, these roles have the Account Access role type. When assigning such a role to a user, you’ll see that they have All entities assigned by default.

  • Entity access roles. These roles provide access to specific entities already available on the account—for example, linode_admin. In Linode API for Identity and Access you’ll see these roles as entity_access. In the list of roles in the UI, in the Roles tab, these roles have the Entity Access role type. When assigning such roles to a user, you’ll need to select specific entities you want to provide access to.

Example

On this account there are two users. User A is the administrator of the account, as they have the account_admin role that includes all permissions to all services. This role applies to all entities currently available on the account, and because this is the account access role, it also applies to entities created in the future.

This user added another user to the account: User B.

User B has has two roles assigned: firewall_viewer and account_linode_creator:

• The firewall_viewer role is an entity access role. This means that when assigning this role to the user, the administrator had to select firewall rules sets User B should have access to: firewall1 and firewall2.
  Each of the permissions included in the role reflects a single API operation:

📘

In the context of firewall, permissions contain the term device instead of entity, but these terms are equivalent.

• The account_linode_creator role is an account access role that applies only to one type of entity, namely Linodes. Each of the included permissions reflects one API operation: