How to Provide a Dynamically generated SAS token to an external Vendor

Question

Hi everyone -

I have an Internal Application (accessed only by the employees of the Organization). My Vendor (accessing from outside) needs to upload a file to a Container in my Blob storage. I am planning to Provide a SAS token URL (with sufficient access to that container) so that they can upload the files. So far so good.

Here are my thoughts.

1. I am planning to programmatically generate a short-lived SAS token URL utilizing User delegated SAS token.
2. I am planning to Provide a Function to the Outside Vendor so that once they run this, they will get a short-lived SAS token URL. And once they get the SAS token URL, they can upload the files to the container.
3. To access the Function by an external Vendor - What is the best mechanism in terms of Security and others. Do i need to provide a Function (which generates the Dynamic SAS token URL) Protected by an API key or Do i need to create a test User account for vendor in Azure AD and utilize an Azure AD authentication for the function.

Can anyone suggest which is the better option ? or are there any other recommended best practices for External Vendors accessing a Blob storage container utilizing SAS token URL?

Thanks!
-Mathew

Answer 1

Hello, user delegation SAS (UDSAS ) are a best practice due being powered/backed by Azure AD credentials, and also due imposing Azure Storage specific constraints, like which Azure Storage resources a client is allowed to access, what permissions they have on those resources, and how long the SAS is valid.

Regarding access for the API of Function developed to manage UDSAS issuance, the most straighforward and logic solution is for your vendor to have its own Azure AD tenant and users so they can get authenticated and UDSAS issued per signed-in user. If your vendor does not want to use Azure AD then you can can obtain tokens using the client credentials flow. Here you will have to provide them with a client secret or certificate (prefered).

For both scenarios is recommended to have 2 app registragions: one for the API or Function and the another one for the client.

For Azure AD AuthN and AuthZ code samples take a look at:

• Azure Functions as web APIs (Both user and client credentials)
• Configure your App Service or Azure Functions app to use Azure AD login (Both user and client credentials)
• Scenario: Daemon application that calls web APIs (Client credentials)
• Tutorial: Create a function app that connects to Azure services using identities instead of secrets (For authorizing your API or Function to Azure Blob Storage without storing credentials)

Let us know if you need additional assistance. If the answer was helpful, please accept it so that others can find a solution.