This pattern allows you to give controlled access to files in Azure blob storage (would work the same way for any storage supporting valet-key pattern, such as S3).

Use case

This pattern should be used when you need to distribute a URL to a blob, and need to authorize access before blobs can be downloaded. In such case, a simple Shared Access Signature is not enough, and Valet Key Pattern can be used to solve the problem. The main use cases are:

  • Fine-grained authorization: although Azure Blob Storage now supports authentication through Azure AD, the authorization is done at a storage account level, which might not be thinly grained enough for the use case (e.g. authorize users to download certain types of blobs only, or certain containers / folders only / blobs marked with metadata / etc.)
  • Monitoring access: log precisely who accessed what blob.
  • Non-AAD authentication system: using another system than AAD for authentication (such as AAD B2C, Auth0, Okta, and so forth) to authenticate users.

Pattern

  1. Client is asking for a file using a structure replicating that of the storage account. Instead of addressing blob storage directly (https://blob.core.azure.net/files/123.txt), this is pointing to your valet (https://my-valet-deployed-somewhere.com/files/123.txt)
  2. Valet is checking context to see if the customer is authenticated. If not, then the client is redirected to the IdP
  3. Client is redirected to IdP, and potentially has to authenticate
  4. Client is redirected to the original URL again
  5. Valet is checking context again and authorizing following your rules. This time the user is allowed in, and so it generates a short-lived Shared Access Signature and redirect to the blob’s url (containing the SAS)
  6. Client is redirected to the blob and accesses it.

This seems a lot but keep in mind that:

  • If the user has already used the system before, and are currently in a session, then steps 2 to 4 might not happen, or they might happen but might not have to re-authenticate and the redirection could be invisible to them (in my experience, sub-second) ; so it’s actually almost a transparent experience for the user.
  • Provided you use Azure Functions or WebApps for that system, EasyAuth is taking care of most of steps 2 to 4, as long as the IdP has an OpenID Connect API (so, even if you don’t use Azure AD) ; so it’s a fairly straight forward thing to implement.

Demo

A demo of this pattern is available on GitHub.