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).
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.
- 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)
- Valet is checking context to see if the customer is authenticated. If not, then the client is redirected to the IdP
- Client is redirected to IdP, and potentially has to authenticate
- Client is redirected to the original URL again
- 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)
- 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.
A demo of this pattern is available on GitHub.