Technology evolves, so Sitecore does too. We are witnessing how Sitecore is transforming their Experience Platform into a cloud-first system. The ball is rolling and there have already been multiple releases since the initial version 8.2 update-1, which enabled the native deployment to Microsoft Azure’s app service platform. The new platform-as-a-service (PaaS) deployment model offers new possibilities, and it will definitely impact how Sitecore solutions are designed, deployed, and operated.

One important topic, which always needs to be in the agenda, is security. How we protect the assets we deploy and operate in the cloud is a broad subject with multiple perspectives. With the rise of PaaS we see also a change of security practices, moving from network to identity secure perimeter.

Azure Active Directory (AAD) is a cornerstone for establishing a proper secure access control and account management policies.

AAD Deployment and Authentication

Let’s quickly cover how to restrict access to Sitecore deployment in App Service using AAD. The goal is to protect the access to content delivery Sitecore App Services and limit it only to internal-to-organization (directory) users. Trying this approach for content management sites will require additional configurations as it can create issues with the default Sitecore login. As of the time of this post, Sitecore does not officially support AD module (nor AAD) with App Service. View the compatibility table for more details.

Let’s assume you already have Sitecore App Service deployment running. If you have not applied any specific configurations, the content delivery and content management sites will be publicly accessible on URL(s) similar to http://{mydeploymentname}.azurewebsites.net/. Let’s assume that access to the website should be limited only to authenticated users (you do not want to have your website yet public available in internet). This can be quickly configure through the “Authentication/Authorization” setting of the particular app by enabling “App Service Authentication” and configuring “Authentication Provider” to use AAD as shown below.

To make these configurations, your account (the one you used to log into the Azure portal) must have permission to make changes to AAD.

Once the configurations are applied, only users registered and authenticated by your AAD will be able to access the website. When visiting it in another browser session (which is not AAD authenticated) you will be presented with a Microsoft login screen.

You can also choose other methods for authentication like Facebook, Google, Microsoft, or Twitter.

As you can see, this is an efficient and quick way to protect your content delivery web apps. Make them accessible to selected group of users with a few clicks of a button and zero code changes. A use case scenario for this approach could be a website which is not yet ready for public internet but can still be accessed privately by users/beta testers from your organization.

Pro tip: IP Filtering Workaround

Until Sitecore App Service has official support for AD/AAD, you can use IP filtering to restrict access to content management web apps with the following configuration in web.config:

For enterprise organizations, securing production content management capabilities or any other test/prod environments is almost always required. That is why deploying Sitecore in a premium plan such as Azure Service Environment (ASE), is likely necessary. ASE offers dedicated App service capabilities provision in its own virtual network, allowing the full benefits of network security, isolation and adding Web Application Firewall (WAF) capabilities.

Finding the right security solution

This blog post presents a very quick approach on how to use the inbuilt Azure security features to limit the access to Sitecore content delivery site deployed in PaaS model. There are definitely more perspectives to delve into, but as a start this the quickest way to protect your assets which are not ready for public eyes.

At Avanade, our customers tend to have much more demanding requirements around security such as connectivity/access to internal on premise systems, integration with Identity Management (IM), globally distributed deployments etc. In those scenarios the use of ASE (which offer much more features) may be required. But, this will be a topic for another post. In the meantime, contact us to learn more about how Avanade’s experts can help you safeguard your technology.