Restricting access to a clients website can be a common practice. This usually means that they will need to have access give to an IP address or a range of IP addresses.
These details can usually be obtained from the clients IT administrators.
Typically during CMS development, you will have two instances of your application – delivery (Front end, with no access to the CMS) and an authoring (Front end and CMS access) and both of these instances will be found in each development environment.
Its usually good practice to restrict all access to development / UAT / SIT environments to your clients IP address. This allows for developments to be approved by the client before being released.
IP white listing will block all connections to the website in IIS unless it is specified on the list. Using a web.config transform would be the way to ensure that the restrictions get applied to the correct environment.
Step 1 – Create the white list.
In App_Config create a new config file called ipSecurity.config
Step 2 – Local IP
<add allowed="true" ipAddress="127.0.0.1" />
Step 3 – Internal IP addresses
This will be your office IP address.
Step 4 – External IP addresses
This will be all of your stake holders in the project external to your company
Step 5 – Add your outbound IP Addresses
These are range of IP addresses that could be used, as Azure currently doesn’t support static outbound IPs. If you need a static IP, you could configure a custom domain.
Step 6 – Error handling
Once locked down by IP, everything that interacts with the website will also be denied access including Application Insights.You will need to included all the IP addresses for Telemetry, Live Metrics Stream and Availability tests.
Availability web test is essentially a ping test that is run every few minutes to ensure your application is alive.
The range of up to date IPs that need to be added can be found here
Step 7 – Adding the list to web.config
Add the following code to you transform to apply the list.
You should only apply this to the sites you need to restrict, with the exception of the public facing delivery application, otherwise your users wound be able to access the site! 😉