Secure Your SaaS Applications with Microsoft Entra Global Secure Access and Source IP Anchoring

Overview

Organizations using SaaS (Software-as-a-Service) or Line-of-Business (LOB) applications often require access only from specific network locations. Microsoft Entra Private Access enables this by routing application traffic through a controlled private network, ensuring traffic originates from a trusted IP address. This process, known as Source IP Anchoring, helps meet network-based access control requirements.

This blog explains how to set up Source IP Anchoring with Microsoft Entra Private Access to enable secure and compliant access to applications. In this example, I demonstrate access to the Jira Service Management application, where access is restricted to specific IP addresses.

Jira's IP Allow List feature allows organizations to grant access only from designated corporate IPs. By leveraging the Private Network Connector, we can route all Jira traffic through a dedicated private network connector. Additionally, Conditional Access (CA) policies can be applied to enforce further restrictions for accessing Jira, ensuring a secure and controlled access environment.

How Source IP Anchoring Works

Here’s the flow:

1. User traffic is acquired by the Global Secure Access client on the device.
2. The traffic routes through Microsoft’s Secure Service Edge, where Conditional Access policies can apply.
3. From there, traffic tunnels into a Private Network Connector.
4. The connector ensures traffic egresses through a dedicated IP address (e.g., 20.126.128.36) that meets the application’s network-based access requirements.
5. Finally, traffic reaches the SaaS application, which validates the connection's source IP.

Diagram: Source IP Anchoring Workflow

Here’s an example architecture showing the traffic flow from the user device to the SaaS app(Jira) via the Private Network Connector (In My example Private Connector hosted on Azure):

When to Use Source IP Anchoring

Source IP Anchoring is necessary when:

• SaaS applications enforce network-based access policies.
• Applications require connections to originate from specific, approved IP addresses.

Note: If your requirement is only for enforcing network location during authentication, consider using the compliant network check instead. It avoids routing traffic through your private network and simplifies the setup.

 

Prerequisites

Before configuring Source IP Anchoring, ensure you have:

• A SaaS app that enforces network-based access control.
• A Microsoft Entra Suite or Private Access license.
• The Global Secure Access forwarding profile enabled.
• The latest Global Secure Access client installed.

Step-by-Step Configuration

1. Deploy Private Network Connectors:

To set up the Private Network Connector, follow these steps:

Choose the Deployment Location:

• You can install the connector in your private network, such as an Azure Virtual Network, AWS, GCP or an on-premises network.
• In my example, I used the Private Network Connector available on the Azure Marketplace. And in this example i am going to access the Jira SaaS Application.

The following screenshots demonstrate the Connector VM deployment using the Azure Marketplace.

**The public IP of the connector will change if your Azure-hosted VM, acting as the Private Connector, is configured with dynamic IP address assignment.

For detailed guidance on planning the Private Network Connector deployment, please refer to my previous blogs:

• Microsoft Entra Private Network Connector
• Microsoft Entra Private Access

These posts provide insights and best practices to help you effectively set up and deploy the connector.

2. Ensure Outbound Connectivity:

• Confirm that the connector has outbound connectivity to the target application (e.g., Jira in my case).In my example, the Connector VM has full outbound internet access enabled in the Azure VM Network Security Group (NSG).

3. Deploy for High Availability:

• To ensure resiliency and high availability, deploy at least two connectors.

4. Secure the Application:

• Provide the connector's public IP address (e.g., 20.126.128.36) to the SaaS application.
  
  
  
• In my example, I added this public IP to Jira's IP Allow List to ensure the application only allows access from my Private Network Connector.
  
  
  
  
  

This approach helps secure the Jira SaaS application by restricting access to trusted, private egress IPs.

Note: A forward proxy between the connector and the destination app is not supported.

5. Configure Source IP Anchoring

Follow these steps to create an enterprise application:

Go to Microsoft Entra Admin Center:

Navigate to Global Secure Access > Applications > Enterprise Applications.
Click New Application.

Define Application Details: 

Enter a name for the application.
Select the Connector Group that routes the traffic (Will select the connector group we created for Azure Hosted Connector).

Add Application Segment: 

Set Destination Type to Fully Qualified Domain Name (FQDN).
Enter the application’s FQDN (My example app: myappname.atlassian.net).
Specify ports: 80 for HTTP, 443 for HTTPS.
Select TCP as the protocol.

Click Apply and Save.

Assign Users and Groups: 

In the Enterprise Applications pane, select your application.
Go to Users and Groups > Add User/Group.
Assign the relevant users or groups.
 

6. Validate the Configuration

The User device IP details are provided by the ISP (ISP Egress IP). In my example, the End user device VM is running in Azure, and the public IP is assigned by Microsoft.

If you're testing this on a laptop or desktop, the IP address will be from your ISP that provides internet access to your device, as shown below.

Now Open the Global Secure Access client on the user device.

Go to Advanced Diagnostics:

Under Forwarding Profile, check that the application FQDN appears in the list.

In our case, the traffic for Jira (myappname.atlassian.net) is being correctly routed and displayed in the client's rules.

Start collecting traffic logs: Navigate to the application in a browser.

when we enter the SaaS application URL, it redirects to the authentication page, and the traffic is already acquired by the Secure Service Edge (SSE) client. As we have Jira SSO configured with Entra ID, allowing us to use the Entra User ID to sign in to the Jira application.

The device is already joined to Entra ID with a valid Entra ID user signed in. Since SSO is configured with Jira, we can use the same login account to access the Jira application. Simply select the connected account and proceed with the sign-in process.

You can Verify the following in you GSA client Traffic Capture:

•     The web app’s FQDN appears in the logs.
•     The Channel field shows Private Access.
•     The Action field confirms traffic is Tunneled.

We have now successfully logged into the Jira application using our Entra ID account, with traffic routed through the Entra SSE Private Connector deployed in Azure.

This specific Jira SaaS application can only be accessed from our Private Connector IP because we configured the IP Allow List in the Jira platform.

As a result, only users who have the Entra Global Secure Access client installed on their devices and have been assigned this Enterprise Application by an admin can access the Jira application.

Now, let's check the end-user experience when the Global Secure Access Client is disabled on the PC. When we try to access the Jira application URL, here's what happens.

As shown in the screenshot below, a network error appears from the Jira SaaS application. This happens because access to Jira is restricted to clients originating from the specific public IP of our Private Network Connector. Any traffic attempting to access the Jira SaaS application URL from other IP addresses is blocked.

Conclusion

Source IP Anchoring with Microsoft Entra Private Access ensures secure, reliable, and policy-compliant access to SaaS and LOB applications. By routing traffic through a controlled IP, organizations can meet strict network-based access control policies seamlessly.

Implement this setup today to enhance your secure access architecture.