Easily manage the contents of your storage account with Azure Storage Explorer. Upload, download, and manage blobs, files, queues, tables, and Cosmos DB entities. Gain easy access to manage your virtual machine disks. Work with either Azure Resource Manager or classic storage accounts, plus manage and configure cross-origin resource sharing (CORS) rules.
As of today, for blob S2S, here's how Storage Explorer currently chooses what auth type to use:
Copy source:
Put source connection on clipboard, create the connection with the following credentials:
If keys or auth are available -> generate either a key-backed or user-delegate SAS token -> add that credential
If auth is available -> add that credential
if anon is available -> add that credential
Perform the S2S copy, choosing a credential from clipboard data. The credential chosen, in preferential order is: SAS token (could be either key-back or user-delete), auth, anonymous
This is breaking for users who can list storage accounts/containers via RBAC, but need to access data plane over ACL. This is because people can get the ability to list storage accounts/containers via the Contributor RBAC role, which also makes it possible for the user to create a user-delegate SAS. This is a problem for users who need to access data plane over ACL because they will lack any data-plane RBAC permissions that would enable the user-delegate SAS to actually work!
The benefit of using user-delegate SAS tokens is that it allows authentication of cross tenant copies. We can't use oauth exclusively auth for cross tenant copies, because AzCopy/the server can only oauth foward the current oauth credentials. The downside of using user-delegate SAS tokens is that it locks authorization to the use of RBAC. Therefore, in an situation where we can simply use auth credentials, we should do so.
So here's what we need to do:
When putting source connection on clipboard, create the connection with the following credentials (same as above!):
If keys or auth are available -> generate either a key-backed or user-delegate SAS token -> add that credential
If auth is available -> add that credential
if anon is available -> add that credential
Perform the S2S copy, choosing a credential from clipboard data. The credential chosen, in preferential order is:
If the source and destination are in the same tenant: key-backed SAS token, auth, user-delegate SAS, anonymous
If the source and destination are in different tenants: SAS token (could be either key-back or user-delete), auth, anonymous
As of today, for blob S2S, here's how Storage Explorer currently chooses what auth type to use:
Copy source:
This is breaking for users who can list storage accounts/containers via RBAC, but need to access data plane over ACL. This is because people can get the ability to list storage accounts/containers via the Contributor RBAC role, which also makes it possible for the user to create a user-delegate SAS. This is a problem for users who need to access data plane over ACL because they will lack any data-plane RBAC permissions that would enable the user-delegate SAS to actually work!
The benefit of using user-delegate SAS tokens is that it allows authentication of cross tenant copies. We can't use oauth exclusively auth for cross tenant copies, because AzCopy/the server can only oauth foward the current oauth credentials. The downside of using user-delegate SAS tokens is that it locks authorization to the use of RBAC. Therefore, in an situation where we can simply use auth credentials, we should do so.
So here's what we need to do: