How to use external IDs to prevent the confused deputy issue - Resource Access Management

When a third-party vendor manages resources across multiple customer accounts, an attacker can exploit this setup to access resources without authorization — a pattern known as the confused deputy problem. External IDs let customers bind a unique token to the trust policy of a RAM role, so the third-party vendor must prove it is acting on behalf of the right customer before assuming the role.

How the attack works

Consider a third-party vendor called Deputy that manages cloud resources — such as log audits, cost tracking, or security monitoring — across many customer accounts. Each customer creates a RAM role in their own account, designates Deputy_Account as the trusted entity, and grants the role the required permissions.

Without external IDs, the trust policy looks like this:

Customer A tells Deputy: "Assume role acs:ram::CustomerA_AccountId:role/MonitorRole to access my account."
An attacker, who has also signed up for Deputy's service, tells Deputy: "Assume role acs:ram::CustomerA_AccountId:role/MonitorRole to access my account."

Because Deputy has no way to verify which account it is legitimately acting for, it assumes CustomerA's role at the attacker's request — granting the attacker access to CustomerA's resources. This is the confused deputy problem: a trusted entity is deceived into performing unauthorized operations on behalf of a malicious one. RAM provides external IDs to prevent this. For more information, see AssumeRole.

How external IDs work

Deputy generates a unique, random external ID for each customer. This ID is not a secret — its security value comes from being unique and bound to a specific customer, not from being confidential. Anyone with permission to view the role can see the external ID.
Each customer adds the external ID to the trust policy of the RAM role that Deputy will assume. The trust policy requires any caller to present this external ID when assuming the role.
When Deputy calls AssumeRole to assume a customer's role, it passes the external ID assigned to that customer. If the ID is missing or does not match the one in the trust policy, the call fails — blocking the attacker's attempt even if they provide the correct role ARN.

Configure external IDs

In this example, the third-party vendor is Deputy with account Deputy_Account, the customer account is Customer_Account, and the external ID Deputy has assigned to this customer is abcd1234.

In Customer_Account, create a RAM role with Deputy_Account as the trusted entity and grant the role the required permissions.

For more information, see Create a RAM role for a trusted Alibaba Cloud account and Grant permissions to a RAM user.

Edit the trust policy of the RAM role to add an ExternalId condition. The condition requires that any caller provide abcd1234 as the external ID.

{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::<deputy-accountId>:root"
        ]
      },
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "abcd1234"
        }
      }
    }
  ],
  "Version": "1"
}

For more information, see Edit the trust policy of a RAM role.

When Deputy assumes the role to access Customer_Account's resources, it provides abcd1234 as the external ID — specifically, it sets the ExternalId parameter to abcd1234 in the AssumeRole request.

For more information, see AssumeRole.
Deputy uses the Security Token Service (STS) token returned by AssumeRole to access the resources in Customer_Account.

Verify the configuration

After adding the ExternalId condition, verify that the protection is active by attempting to call AssumeRole without an external ID. The call must fail with an access denied error. If it succeeds, the condition has not been applied correctly — review the trust policy and confirm that sts:ExternalId appears under the Condition block.

Usage notes

Generate one external ID per customer account. Use a random string to prevent predictability.
External IDs are not confidential. Their security value comes from uniqueness and binding, not secrecy. Do not rely on keeping the external ID secret as a security control.

References

Use a RAM role to grant permissions across Alibaba Cloud accounts