Access Control for Queues

If you're using Query or SOAP, you can use the Amazon SQS access control features to assign other users permissions to a queue, a particular message, or multiple messages. The SQS access control features are not available with the REST API.

The Query and SOAP APIs include three actions related to access control:

A permission is the type of access you give to a grantee (the user receiving the permission). Amazon SQS supports the types shown in the following table.

PermissionDescription

ReceiveMessage

This grants permission to receive and delete messages in the queue.

SendMessage

This grants permission to send messages to the queue.

FullControl

This permission includes all possible actions you can perform on queues and messages. When you create a queue, only you (as the queue owner) can modify the access control permissions on the queue. You cannot transfer ownership of a queue to another user. However, if you grant another user FullControl permission to the queue, that user can perform all possible actions on the queue and its messages, including setting access restrictions, removing your access rights to the queue, and deleting the queue.

[Caution]Caution

Be very careful when granting FullControl permission because the user will be able to remove your rights to the queue or delete the queue.

Grants for each of the different permission types are considered separate grants by SQS, even though FullControl includes the access provided by the other two permission types. For example, it is possible to grant both FullControl and SendMessage grants to a user, even though a FullControl grant includes the access provided by SendMessage. If you list the grants for the user, both FullControl and SendMessage grants are listed. Conversely, if a user has only FullControl, if you request to list all SendMessage grants for the queue, the user's FullControl grant is not included in the list, even though FullControl includes SendMessage.

This same concept applies when you remove a grant. If a user has only a FullControl grant, requesting to remove a SendMessage grant does not leave the user with a ReceiveMessage grant. Instead, the request does nothing, because the user did not previously possess an explicit SendMessage grant.

If you want to remove FullControl and leave the user with the ReceiveMessage grant, first add the ReceiveMessage grant, then remove the FullControl grant.

When you make an access control request, you must specify the grantee using one of the following methods:

With the canonical method you specify CanonicalUser as the value of the type attribute for the Grantee element and provide a canonical representation of the user. This canonical representation is returned by a ListGrants request.

The canonical representation includes two parts:

  • IDA system-assigned string that uniquely identifies the user
  • DisplayNameA human-readable string determined as described below

The required XML format is:

<Grantee xsi:type="CanonicalUser">
   <ID>a9a7b886d6fd24a52fe8ca5bef65f89a64e0193f23000e241bf9b1c61be666e9</ID>
   <DisplayName>customerNickname<DisplayName>
</Grantee>

SQS determines the DisplayName value for a user as follows:

  • If the user's Amazon.com account has a public nickname associated with it, that nickname is used.

  • Otherwise, the first component of the user's e-mail address is used (the characters before the @ symbol).

The DisplayName value returned by SQS for a particular user is not unique and might change over time. For example, if the user changes the e-mail address for the Amazon.com account or updates the nickname, the change is reflected in subsequent ListGrants responses.