Use Linode API to configure single sign-on (SSO) with federated identity providers through SAML 2.0.
With an SSO infrastructure, users sign in once to Cloud Manager, Linode CLI or other Linode clients, and have subsequent access to all resources they are authorized for.

There are many benefits with using SSO with SAML:

• Easy integration. Swiftly integrate with external identity providers you’re currently using.
• Increased adoption. SSO makes it easier to access applications and reduces the barriers of use for resources.
• Uniform security layer. SAML is platform-agnostic, allowing enterprise architects to implement a uniform security layer between existing layers.
• Improved productivity. Centralized password management in the identity provider saves time and makes users more productive.

Single sign-on for Akamai Cloud requires SAML Assertion to be always signed.

To learn more about Identity and Access and single sign-on terminology, see Identity and Access Terminology.

📘

If you’re using Single sign-on (SSO) with Akamai Control Center, it will continue to work as an alternative for single sign-on for Akamai Cloud.

User journey using the SSO login for Cloud Manager

This is the user journey with the SSO login enabled.

1. A user opens cloud.linode.com
2. The user enters their username and clicks Continue.
   Result:
   1. Cloud Manager, as the service provider, checks for an SSO configuration for the user.
   2. The configuration is detected. Cloud Manager sends the SAML request to the user’s identity provider.
3. The user is redirected to the Identity provider login page where they need to enter their credentials.
   Result: Cloud Manager receives the SAML response from the identity provider:
   1. IDP digital signature is validated.
   2. The assertion is extracted and verified.
   3. The received identity is mapped to the entered username.
4. The Authenticated user is redirected to the initially requested cloud.linode.com endpoint.

Emergency access accounts

An emergency access account, also known as a break-glass user, is a highly privileged user within Akamai Cloud. This account is designed to be used only when standard authentication mechanisms, specifically single sign-on (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).

👍

An emergency access account in Akamai Cloud is fundamentally no different from any other standard user. The responsibility for the creation, management, and security of this user resides entirely with the customer.

Why should you configure an emergency access account?

The use of single sign-on login with providers such as Okta, Microsoft Entra ID, or Google Workspace, can help enforce security policies and simplify user management. However, several scenarios can result in a total lockout:

• IDP Outage. Your single sign-on provider experiences a service disruption, preventing all federated users from logging in.
• Misconfiguration. An administrator accidentally changes the configuration in Akamai Cloud or the IDP, breaking the trust relationship.
• Certificate Expiration. The signing certificate used for SSO expires, immediately invalidating all login attempts.

👍

Scenario example

Your organization uses an external identity provider for Cloud Manager access. This identity provider experiences an outage lasting a few hours. Without an emergency access account, your DevOps team can't scale resources, reboot frozen instances, or manage firewalls during this window.

Setup best practices

To ensure the emergency access account is effective and secure, it’s highly recommended to adopt the following standards:

1. Exclusion from SSO. The emergency access account should be excluded from the SSO to make sure they are not authenticated by the Identity Provider. The user should continue to use the password to authenticate. To exclude the user from the IDP configuration, run the Update excluded users operation in Linode API (link to API documentation).
2. Access to email address. Make sure emergency access accounts have email addresses that can only be accessed by the approved individuals. To check users’ email address, see View all users. Using the same email address for multiple users is allowed in Cloud Manager, but it’s strongly unadvised for emergency access accounts.
3. Minimal quantity. For larger organizations, it’s best to create more than one emergency access account, but no more than three. This provides redundancy in case one set of credentials fails or is lost, without unnecessarily increasing the attack surface. This is not a limitation of the system but it is best practice to keep a balance between redundancy and availability of emergency access.
4. Required permissions. The emergency access accounts should have the account_admin roles assigned. Those users need to have the ability to modify account settings, specifically the ability to fix or disable SSO settings to restore access for the rest of the team. To update the users’ role, you can use Cloud Manager or run the Linode API.

Protecting the credentials

Emergency access accounts possess privileged access and need to be safeguarded with a higher degree of scrutiny than standard, daily-use accounts.

Two-Factor Authentication (2FA)

To ensure the emergency access account remains accessible regardless of individual availability, the account needs to be secured using a software-based TOTP authenticator managed through a controlled, multi-user environment rather than a personal mobile device.

• Administrative Vault Storage. Configure the TOTP seed (the secret key) within a centralized, encrypted corporate credential manager. This allows the account owners to access the one-time authentication code if a specific administrator is unavailable.
• Offline Seed Redundancy. Capture and document the secret key and the scratch code generated during the initial 2FA setup in Cloud Manager. The scratch code is an alphanumeric string that can be used once in place of the OTP token. To learn how to configure 2FA, see Manage 2FA on a user account.
• Physical Recovery Manifest. Store the secret key and the scratch code generated during the 2FA authentication together with the security questionnaire in a physical, tamper-evident envelope. This envelope needs to be kept in a secure and onsite safe. This ensures that even in a grid-down scenario where digital vaults might be inaccessible, the account can be recovered.

Credential splitting (the two-person rule)

For maximum security, use a split knowledge approach for the password:

• Generate a long, random 32+ character password.
• Split the password into two halves.
• Give part A to Executive or Manager 1 and part B to Lead Engineer 2.
• Store the full password in a physical envelope inside a secure safe that requires different keys and combinations held by different people.

Monitoring and auditing

The emergency access accounts should be used for emergency cases only, such as catastrophic failures, critical security incidents,or immediate operational needs. A core security principle requires this account to be nearly inactive, aiming for 99.9% inactivity.

Any significant changes to this user need high-priority investigation. When you notice such an event, a full audit can validate the cause, confirm legitimacy, ensure access was necessary, and promptly restore the account to its required normal state. Akamai Cloud notifies changes in the user settings via email; therefore, it is very important to monitor for any changes occurring to the emergency access account.