Restrict access to static website hosted on azure storage to intended users

Question

I hosted a simple website in Azure storage using the static website feature. The url of the website is now publicly available. (anyone with the url can access the website). But my intention is to provide access only to the users who I want to. Is there a way that can restrict the public access to the static website hosted in Azure storage?

Equanimous

Perhaps, If you'd like to, you could restrict the access to storage account with its firewall.learn.microsoft.com/en-us/azure/storage/common/… but this way could not restrict real user just networking access from that user. – Rising

@NancyXiong My intention is to make the static website available to users who use an other application which i develop and the users of that app only should be able to access this static website. for instance i want to host the documentation in the static website and make it available to the users who signup to use my application. I intend to have the documentation private. – Equanimous

@Equanimous did you find a way to solve this? I am in the same situation. – Stavro

@Stavro we used another way to publish the documentation and I haven't looked into this further – Equanimous

I know this is an old post, just found the below link which seems to address the problem learn.microsoft.com/en-us/answers/questions/149991/… – Miniver

I am also looking for the solution; none of this seems to help. – Joses

You could put the site behind an AppGateway, then use client certificate authentication to block who can access that (i.e. only those users the cert's been shared with)... Not quite what you want, but it's the closest I've been able to get. Otherwise I think the only solution is to use an App Service Environment: learn.microsoft.com/en-us/azure/static-web-apps/… (though that costs more outside of their free tier (which isn't intended for corporate use / doesn't come with SLAs... though it may be OK to use if your site's non-critical...I don't know the rule)) – Legman

ps. I just asked the same here reddit.com/r/AZURE/comments/117nhqf/… - there's a few more recent answers (no way to do it directly, but some fairly low cost solutions) – Legman

Answer 1

Static website hosting makes the files available for anonymous access. If you need to control who can access the files, you can store files in Azure blob storage and then generate Using shared access signatures (SAS) to limit access.

The links in the pages delivered to the client must specify the full URL of the resource. If the resource is protected with a valet key, such as a shared access signature, this signature must be included in the URL. https://learn.microsoft.com/en-us/azure/architecture/patterns/static-content-hosting

You can try configure a CDN endpoint to hit a private Blob container (do not use Static Website feature because the endpoint is completely public) through SAS tokens. Azure CDN supports this scenario natively – in worst case you can write rewrite rules to redirect requests to the Blob endpoint with SAS tokens.

Using Azure CDN with SAS

Strader

Answer 2

You can use SAS (shared access signature)

• You can keep your blobs in the static website as Private access (only blob owner can access with storage account key)
• Then you can have simple service to authenticate and authorize your clients (if many) and generate SAS tokens for them to access the blob (web page). This service can also renew the tokens for them.
• If it's a limited number of people you can generate SAS and simply share a link with clients.

You can do this at the granularity of the blob (web page) so you can authorize some to read some pages, while they can't read others ...etc.

Boeschen

Thanks Saher. I tried reading about the SAS token but am confused/clueless how to make use of this. i am a beginner in this field. Can you please provide a reference of a working demo or any useful reference of how to achieve it? So when the users try to access the link for example: https://<accountname>.z1.web.core.windows.net/ only the user I intend must get to the home page and the other should not. – Equanimous