Specify the API caller

更新时间:
复制 MD 格式

This topic explains how to specify the actual api caller when you call a DMS API. When an api caller is specified, a successful call provides a clear audit trail of both the user who performed the proxy operation and the user who initiated the request.

Background

Typically, when you call a DMS API, you use an access key (AccessKey ID and AccessKey Secret) from an Alibaba Cloud account or a RAM user. DMS then records the account UID associated with the access key for operation audits.

In some scenarios, multiple users may share a single access key pair to call DMS APIs. In these cases, DMS only records the key owner, not the actual caller. This makes it difficult to accurately trace each operation back to the true initiator, hindering accurate auditing.

To address this issue, DMS has added the RealLoginUserUid request parameter to certain APIs. This parameter lets you specify the account UID of the actual api caller. After a successful call, DMS displays information about the actual caller and their account UID. For a list of supported APIs, see Supported APIs.

Prerequisites

To specify the api caller, the Alibaba Cloud account making the call must have the AssumeUser permission. DMS administrators have this permission by default.

Note

The AssumeUser permission is part of the ABAC (Attribute-Based Access Control) capability, which is currently in a canary preview. If a regular user requires this capability, they can ask a DMS administrator to grant them the administrator role. For instructions on assigning roles to users, see Edit user information.

Supported APIs

Example

This example demonstrates how a regular user, B (dmsuser_test), can use administrator account A (db_doc) to call the ApproveOrder API.

  1. Log in to the OpenAPI Explorer as administrator account A (db_doc).

  2. On the API page, enter the RealLoginUserUid parameter and other required parameters, and then click Make a Call.

    In this example, enter the Alibaba Cloud account UID of user B (dmsuser_test).

    Set the ApprovalType parameter to AGREE.

  3. After the call succeeds, go to DMS to view the information of the actual operator.

    The audit trail shows that user A (db_doc) approved the ticket on behalf of user B (dmsuser_test).