Challenges with Public Cloud

One of the oldest problems facing cloud infrastructure services has been access control. Ensuring that resources can be accessed by users and services that need to access them and not by anything else has been problematic when those services are delivered through the public internet. Even as late as last year, cybersecurity data firm listed over 35,000 publicly accessible and unsecured databases, most of which were cloud-hosted. That’s over 35,000 data breaches that have likely already happened because of misconfigured cloud resources. In short, the problem with the public cloud is that most resources shouldn’t be public.

Service Endpoints to the Rescue

Azure’s first step in service access control was the service endpoint. A service endpoint allows virtual networks to use private IP addresses to route traffic to an Azure service’s public IP address. But more importantly, it also allows you to deny traffic over the service endpoint unless it comes from its subnet. This effectively denies access to all traffic coming in from the public internet, making your Azure service accessible only to other Azure services and to selectively whitelisted IP addresses.

This approach has some limitations, potentially the biggest being that your service still has a public endpoint. It has a firewall in front of it, but if you only want other Azure services to connect to your private database, why should that database server allow traffic over its public IP address? Availability is another issue. Some Azure services, such as Azure Kubernetes Services, don’t support service endpoints. The network traffic pattern is also inefficient since Azure services using service Endpoints need to interact through public IP addresses. Finally, you have the issue of scope. Service Endpoints are scoped to the service, meaning any service in that subnet has access to the service. This means either a high degree of granularity in subnets, an administrative burden, or simply ignoring the access issue and hoping nothing happens. And while storage accounts have a third option, service endpoint policies, they only apply to storage accounts.

AIS used Microsoft Azure services to migrate Windows 2016 Servers to Azure PaaS, reducing costs and scaling application performance as needed.

Private Endpoints: The Next Step

It’s not that Service Endpoints were a bad idea or were poorly implemented. Rather, the needs and usage of the public cloud have evolved rapidly. In response to evolving needs, Microsoft introduced another way to control connections to a service. Private Endpoints allow services to be accessible through their private IP addresses and Private Link, making connections between private IP addresses possible. And that doesn’t just mean private IP addresses in Azure. You can connect to your Azure instance from your on-prem network without leaving your firewall or using the public internet with the correct Domain Name Server (DNS) configuration.

To that end, there is no public IP address for a private endpoint. An Azure service can have both a private endpoint and a public endpoint. Creating a private endpoint does not automatically deny traffic over the public endpoint. However, if you take the extra step of denying all publicly routed traffic, you have isolated your Azure service far more effectively than if you had used a service endpoint. We can take this private connectivity a step further. It’s possible to integrate a private endpoint with a private DNS zone in Azure, resulting in private endpoints that can accept traffic from on-premises networks without routing through the internet. It’s as if the Azure service was part of the on-premises network. Finally, private endpoints solve our scoping and availability problems. Private endpoints are available on more services than service endpoints. For a full list, reference Microsoft documentation on Private Endpoint Availability and Service Endpoint Availability. Private endpoints can be scoped to a specific resource, such as a storage account, or even a sub-resource, such as specific blobs or tables in the storage account. Because Azure Active Directory can govern access to the private endpoint, this offers a very granular Role-Based Access Control (RBAC) for Azure resources.


Private endpoints aren’t all sunshine and roses, however. They do come with some significant downsides to consider. First, they aren’t free. Private endpoints are charged by usage, while service endpoints are free. Secondly, private endpoints require more setup than service endpoints because you need to set up and configure DNS. Azure services have Fully Qualified Domain Names (FQDN) that resolve to public IP addresses, so you must configure DNS so that the public address resolves to the private IP of its private endpoint. In the end, it takes more to use private endpoints, but you get more when using them.

Putting It All Together

Private Endpoints involve a fair number of steps and a good bit of supporting infrastructure. Because of that, a practical implementation might help visualize how everything fits together. Fortunately, Microsoft has provided a thorough set of tutorials and quickstarts to help you get your hands dirty. If you try these, and I encourage you to do so, please remember to keep an eye on how services are charged and tear down your work so that you don’t receive a surprise bill.


Private Endpoints are an evolution of Azure infrastructure. The upfront configuration effort and ongoing service billing for use means that you should carefully consider whether your organization needs them. For example, if you need to block all internet traffic to a service while making services available to on-premises traffic, or if you need to secure specific sub-resources in your virtual network, Azure now offers that capability through private endpoints.

What is Azure Web Application Firewall (WAF)?

Azure Web Application Firewall (WAF) filters, monitors, and blocks HTTP traffic. It uses Open Web Application Security Project® (OWASP) rules to protect your application. It also provides centralized protection to web applications from common exploits and vulnerabilities and protects against threats and intrusions.

Supported Services

We have three different options to create a WAF in Azure:

  • Azure Front Door: Global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications.
  • Azure Content Delivery Network (CDN): Global CDN solution for delivering high-bandwidth content. It can be hosted in Azure or any other location.
  • Azure Application Gateway: Web traffic load balancer that enables you to manage traffic to your web applications.

Azure Front Door

Azure Front Door provides centralized protection for our web applications. It prevents malicious attacks close to the attack sources before they enter your virtual network.

As shown in the below image, we placed WAF at Azure network edge locations. It will inspect every incoming traffic, so it will prevent malicious attacks from entering the virtual network.

Global WAF Policy
Reference –

Azure Content Delivery Network (CDN) Service from Microsoft

Azure Content Delivery Network (CDN) provides a global and centralized solution for our web content. It will reduce load times, bandwidth, and speed responsiveness of the application.

As shown in the image, WAF deployed on Azure network edge locations around the globe. A WAF policy easily links to any CDN endpoint in your subscription. New rules can be deployed within minutes and respond quickly to changing threat patterns.

Content Delivery Network
Reference –

Azure Application Gateway WAF

Application security is strengthened by WAF integration into Application Gateway. Protect your web applications from web vulnerabilities and attacks without modification to back-end code. We can protect multiple web applications at the same time. An instance of Application Gateway can host up to 40 websites protected by a web application firewall. In addition, we can custom WAF policies for different sites behind the same WAF. As shown below, we can also Protect our web applications from malicious bots and XSS attacks, SQL Injection, and other vulnerabilities by using Application Gateway WAF.

Application Gateway
Reference –

WAF Modes

WAF policy can be configured to run in the following two modes:

  • Detection mode: When running in detection mode, WAF doesn’t take any actions other than monitoring and logs the request and its matched WAF rule to WAF logs.
  • Prevention mode: In prevention mode, WAF takes the specified action if a request matches a rule. If a match is found, no further rules with lower priority are evaluated. Any matched requests are also logged in the WAF logs.

WAF Policy and Rules

WAF policy consists of two types of security rules:

  • Custom rules that are authored by the customer
  • Managed rule sets that are a collection of Azure-managed pre-configured set of rules

Custom rules are reviewed before processing the rules in a managed rule set. A rule is made of a match condition, a priority, and action. If such a match is processed, rules with lower priorities aren’t processed. We can create rules that meet our requirements by combining managed and custom rules. For example, we can configure custom rules based on IP address, Geographical location, HTTP parameters, size constraint, rate limiting.

WAF Actions

WAF customers can choose to run from one of the actions when a request matches a rule’s conditions:

  • Allow: Request passes through the WAF and is forwarded to the back-end. No further lower priority rules can block this request.
  • Block: The request is blocked, and WAF responds to the client without forwarding the request to the back end.
  • Log: Request is logged in the WAF logs, and WAF continues evaluating lower priority rules.
  • Redirect: WAF redirects the request to the specified URI. The URI specified it is a policy-level setting. Once configured, all requests that match the Redirect action will be sent to that URI.

WAF Monitoring

Monitoring the health of your WAF and the applications that it protects is supported by integration with Azure Security Center, Azure Sentinel, and Azure Monitor logs. WAF instances are integrated and send alerts and health information to Security Center for reporting. Azure Monitor allows us to track diagnostic information, including WAF alerts and logs.

Monitor and track diagnostics
Reference –

How To Deploy Azure Web Application Firewall (WAF) with Azure Application Gateway

  1. Create WAF Policy to configure the firewall. Search Web Application Firewall Policy click and Add policy. Then we need to select the type of WAF, Resource Group, Policy Name, and state.
    Basics of creating WAF Policy
    Reference –
  2. Select Prevent or Detect mode based on the requirement.
  3. We can configure a custom rules section to match the rule and rate limit rules. As shown in the image below, we can limit the threshold value and duration.
  4. Review your settings, then create!
Adding rate limit rule to match
Reference –


All organizations are exposed to a variety of malicious attacks. To protect from such, we can use Azure WAF to protect the application even from the most sophisticated threats before they reach your servers. To learn more, check out Microsoft documentation on Azure WAF or reach out to AIS.

Your cloud adoption efforts require sound security, compliance, and governance. It is our mission to make those requirements a reality. Contact AIS about our Security and Compliance Consulting Services.

The identity team of the internal AIS Microsoft Power Platform Hackathon delivered a flexible solution that could handle any of these use cases. Read on to learn how we did it.

Power Apps Portals are external-facing web applications that allow external users to interact with Microsoft Dataverse. It often serves more than one set of users, such as customers, employees, and partners. Therefore, it is critical to have a good authentication scheme and identity management for the Power Apps Portal applications.

Options Considered

We explored two authentication options to solve our app modernization challenge.

  1. Power Apps Portals authentication features
  2. Azure Active Directory B2C

Power Apps Portals provide a simplified experience to create and manage authentication settings and identity provider configuration. Besides providing access to internal users through Azure Active Directory, it supports various third-party identity providers such as Microsoft, Google, Twitter, Facebook, LinkedIn through authentication protocols like OpenID Connect and OAuth.

It also allows other authentication mechanisms such as SAML 2.0 and WS-Federation. All in all, it covers many use-cases of user access control to the portal application.

Azure Active Directory B2C
is an Identity and Access Management (IAM) service that provides business-to-customer identity as a service. It enables customers and partners to use their preferred social, enterprise, or local account identities to get single sign-on access to business applications.

Azure Active Directory
Figure 1: Microsoft Azure Active Directory B2C Architecture

Rather than using Power Apps Portals authentication and managing a different set of user identities in the application, we chose to delegate this responsibility to AAD B2C. We made this decision because AAD B2C:

  1. Provides centralized change management
  2. Decouples identity from the application
  3. Has support for advanced security use cases

Centralized Change Management

If every portal application configures authentication providers separately, it duplicates their effort, and managing different providers multiple times can be cumbersome. Instead, we can centrally configure the identity providers using AAD B2C. In addition, AAD B2C gives us the flexibility to make all changes concerning identity, security, and access control in one place.

If the security need of these applications differs, we can define them in custom policies. Applications with the same security need can reuse the same custom policies. This flexibility enables us to define and modify identity experiences with minimal to no changes to the applications.

Application Identity
Figure 2: Application Identity configuration Vs. Centralized Identity Management using AAD B2C

Decouple Identity from Applications

Using AAD B2C removed the responsibility of user administration from the portal application. Decoupling IAM capabilities from applications mean the developers can focus on delivering business value. However, this does not mean the developers can ignore the security aspect of the application. Instead, it means IAM is a pre-condition to access the application, and it is being handled separately by the IAM provider.

As a single responsibility principle, developers should focus on applications, and security experts should focus on IAM. Power Apps Portal integrated with AAD B2C does just that.

Experience hackathons, boot camps, lunch and learns, and more at AIS.

Advanced Security Features

AAD B2C provides state-of-the-art identity and access management capabilities. Using Azure AD B2C as the authentication provider, we can leverage some of the advanced security features mentioned below.

Custom Policies

Custom policies are configurations that define the behavior of the AAD B2C tenant. We can use these policies to a custom trust framework for our organization. These policies can help to customize various aspects of our AAD B2C identity platform, including:

  • A tailored experience for sign-ups, sign-on, profile & password management process
  • Interact with each step in the login process.
  • Set custom claim
  • Custom validation of Technical profile.
  • Integrate with external systems using REST API

It can improve organizational security by requiring end users to go through a workflow to use an additional authentication method. These policies also allow organizations to address security concerns on an application-by-application basis.

Conditional Access

This feature allows applications to fine-tune user access based on contextual factors such as user type, device, location, and session and then decide whether to allow, deny, or restrict user access. In addition, the conditional access feature provides high security to the applications that demand it. These policies give greater control over how and when our users access corporate resources.

For example, we can enforce a conditional access policy where users can access an application within a geographic region, but they need to provide multi-factor authentication (MFA) otherwise.

Identity Protection

AAD B2C also protects against risks by automatically detecting threats based on the always-on monitoring access behavior. The security teams will receive notifications whenever there are any suspicious activities. They can use automation and custom policies to block or restrict the access of such users. Applications protected with this feature will be more secure.

B2B Collaboration

Through AAD B2C identity providers, we can onboard multiple partners or vendors for business-to-business collaboration. We can securely share the enterprise applications with guest users from any other organization while maintaining control over their access. It works safely and securely with external partners, even if they do not use Azure AD. Whereas managing multiple B2B settings in the Portals app will be cumbersome, if not impossible.

Configuring Azure AD B2C Authentication

We used the techniques described below to configure AAD B2C authentication when modernizing our legacy application to MPP. At a high level, it requires two steps:

  1. Register an application in Azure AD B2C
  2. Use the registered application in the Portal app.

Registering an App in Azure AD B2C

First, we should create a new app registration in the Azure AD B2C tenant. We can use an existing app registration as well. Refer to this link for detailed instructions.

The app registration should be of a Web Type, and we should set its Redirect URI as the portal URL. We should then create a User flow for Sign-up and Sign-in. Optionally, we can create a password reset user flow as well.

Redirect URIs Web

After setting up these configurations on the Azure AD B2C tenant, we should have the following things handy.

  • Authority: The issuer URL defined in the metadata of the sign-in and sign-up policy flow
  • Client Id: The unique Id associated with the application created in the Azure AD B2C tenant.
  • Redirect URL: The URL where the Azure AD B2C will send the authentication response.
  • Policy Id: The Id associated with the default sign-up and sign-in User flow.

Using the App Registration in the Portal App

After creating the application registration in AAD B2C, the next step is configuring our PowerApps Portal to interact with Azure AD B2C. We can select the portal application and navigate to the authentication settings and select AAD B2C as the provider.

Identity Providers
Figure 3: Identity providers supported in a Power Apps Portal Application

Save the authentication settings after setting the values collected from the previous steps (as shown in Figure 4). At this point, the portal application is configured to use AAD B2C for authentication. Refer to Microsoft documentation for more detailed instructions.

Azure AD B2C configuration settings window


There are definite benefits of using Azure AD B2C as the authentication provider for portal applications. It provides seamless and centralized user access management with additional security features. At the same time, it decouples the business applications and their developers from the hassle of user access management.

Thank you to the Identity team for sharing their experience:

  • Lav Kumar (team lead)
  • Davood Khan

Recommended Reads

How We Modernized a Legacy App using Power Platform

In May, AIS held an internal hackathon for Microsoft Power Platform to expose our team to the platform, concepts, approaches through hands-on experience and to demonstrate the role Power Platform plays in modernizing legacy applications in the cloud.

The Microsoft Power Platform Hackathon was an opportunity for our enthusiastic team to modernize a legacy e-commerce (E-shop) application using Microsoft Power Platform. The legacy application, the deployment of eShopOnWeb, helped users find a product of interest by browsing and filtering. Users could also add products to their cart and checkout. The app also provided an interface for administrators to add, update, or delete products from the catalog. The idea behind this hackathon was that we could build this application on top of the Microsoft Power Platform or Low Code application platform instead of using classic ASP, ASP.NET, and GSP. We wanted to write the application using Power Portal to drag and drop to use existing components. 

A new system was developed to replace the legacy e-commerce application with the complete feature parity. The solution included a Power Apps Portal with the same “look and feel” functionality. We used Dataverse as the persistent layer instead of SQL server and integrated it with new communication methods such as sending emails and text messages to users. Additionally, we used a Web API to communicate with Legacy Reporting Systems using Power Platform Connectors, providing secure access to the new system using Azure Active Directory B2C.

In addition, the team explored ways to backup and source control the solution and automate the deployment from one environment to another. The diagram below represents the architecture of our final solution.

Final Power Platform Blog

It is named ‘Work Less, Do More,’ Power Platform replaces the work that might take many days or months to a few hours. So let’s dive in and learn how we arranged all these pieces and modernized the legacy application using Microsoft Power Platform.

AIS provides employees with opportunities to learn and grow in their careers. Won't you join us?

Technical Approach

Our main motivation was to identify the appropriate approach to bring applications to scale. Our innovative approaches and technical depth have earned us the privilege of experience in designing, implementing, and modernizing some of the most complex cloud solutions. The application was divided into different components, which were developed by individual teams.  All the components were then pulled together to provide the complete Power app solution.

When dealing with legacy applications, we looked at past examples of our approaches from experience and have outlined them below: 

  • Rehost: A direct cloud lift and shift. This is a faster, less resource-intensive migration that moves your apps to the cloud without any code modification. The rehosting approach to app modernization is capturing the on-prem environment that runs an application (the servers) and directly moving that to the cloud as virtual servers. In this approach, the environment hosting the application is modernized, but the core application itself is not significantly offered.
  • Refactor: This approach is about modernizing legacy applications by rearchitecting to target cloud-native “serverless” technologies where possible. Refactoring typically requires more significant recoding of the existing application, however, this method takes advantage of the best of what the public cloud has to offer – managed offerings for all application components. In this approach, we re-architect existing applications and deploy them as Platform as a Service (PaaS).
  • Replatform: Essentially, this approach is somewhere in between Rehost and Refactor, because the entire VM is not moving to the cloud. This application will be containerized and run on top of Kubernetes.
  • Reimagine: This is typically thought of as a Greenfield cloud-native rewrite, which is why code changes are high, even though you will eventually end up with a low operating cost.

The idea of Power Platform and low code applications is that you can get to the Reimagine approach without having to spend a lot of effort in building a cloud-native application.

In this section, we are going to highlight these components and how they were implemented in our solution:

The front-end team focused on building the Power Apps Portal for the end-users and a model-driven app for the administrators. The Portal allowed the users to browse through the product catalog, add an item to the cart, place an order, view their past orders, and manage their profile. The model-driven app allowed administrators to manage the product catalog just like the legacy application. The team used Portals Web API to fetch data from Dataverse and used Liquid templates for web pages.

The data team focused mainly on using Microsoft Power Platform Dataverse as the persistent layer for both the Portal and the admin app. They also migrated schema and data from legacy datastore to Dataverse by exploring various techniques, including Dataflows, CSV imports, and custom code.

The integration team focussed on leveraging existing Power Platform connectors to add new functionality to the system. For example, the system sends the order confirmation email to the user using the Office Outlook connector in the Power Automate Flow. Similarly, it sends text messages to users through the Twilio Connector. The team also leveraged SQL Server Connector for data sync so that the legacy reporting systems remained unaffected.

The DevOps team automated the portal deployment process using Power DevOps Tools and deployed the solution across three environments (dev, test, prod). Since Microsoft Power Platform does not support source control and versioning, the team used Azure DevOps as the solution repository and version control.

The identity team focused on providing secure access to the Portal to a different set of users. The team used Azure AD B2C to decouple identity and access management from the Portal application.

Stay tuned! We will be publishing a blog for each team for a deeper dive into their individual focuses for this hackathon.

Lessons Learned

Ultimately this hackathon proved that Power Platform is a great app modernization solution for the following reasons.

  • We can use Portal as a modern low code alternative to create websites and interact with data in Dataverse.
  • Model-driven apps provide a rich no-code design environment to create applications and share quickly.
  • We can quickly build secure apps using connectors.
  • Innovate and improve business, as these connectors are easily customizable, and end-users can easily change or create the content for Email or SMS Templates.
  • With the help of Power Platform build tools, we can quickly deploy the solution into various environments. Increase the release frequency.

AIS architected, developed, and deployed a secure global health solutions management application and digital marketplace built on Power Platform.

Thank you to the Internal Power Platform Hackathon Technical Deep Dive team
Authored by Lav

Covers experience from all teams:

Front end
Ritika Agarwal (team lead)
Devyanshi Tiwari
Pooranendu Patel

Jagrati Modi (team lead)
Souradeep Banerjee
Nikhil Grover

Kranthi Kiran (team lead)
Varalika Bishnoi
Sravan Kumar
Pavan Bandi

Vikram Reddy (team lead)

Lav Kumar (team lead)
Davood Khan

Recommended Reads