What is Portnox Zero Trust Network Access (ZTNA) and how does it work?

Portnox™ Zero Trust Network Access (ZTNA) provides secure access to both public and private resources by enforcing authentication and device validation before allowing any connection. It does not rely on network location or trusted zones. Instead, access is granted after verifying the user’s identity via a certificate and confirming that the device meets defined security requirements using either Portnox AgentP or Microsoft Intune/Jamf.

ZTNA supports two access methods:

  • Conditional access: Used when the resource (application or service) is an SSO web resource located in a public space and already accessible over the internet, such as a cloud service or a VPN front-end. With ZTNA, access is secured using certificate-based authentication and device validation, which is more secure than typical SSO. This method is useful for employees working either in the office or remotely who need to access public cloud resources (applications or services).

  • Remote private access: Used when the resource (application or service) is hosted in a private, secured network, such as on-premises or in a private cloud. This method allows users in public or untrusted networks – such as remote employees working from home – to securely access internal services. It replaces traditional VPNs with a simpler, more maintainable alternative.

ZTNA combines the functionality of two older Portnox products – Conditional Access for Applications (CAA) and Remote Private Access (RPA) – into a single product. ZTNA covers all the needs of an enterprise for secure employee access to resources no matter where they are located.

ZTNA conditional access

In this topic, you will learn what is the conditional access method in Portnox™ Zero Trust Network Access and how it works.

ZTNA conditional access service provides secure single sign-on user access to resources (web applications).

In a traditional single sign-on (SSO) access model, the user can access the web application from any device, as long as the user is authenticated. In the ZTNA model, an extra security condition is added: only specific user devices may access the application, and only if these devices meet the security requirements defined by the administrator.

For example:

  • Traditional security model:

    1. The user authenticates with the single sign-on provider using their email address and a password (optionally with multi-factor authentication).
    2. The user can access the web application from any device.

  • The ZTNA conditional access model:

    1. The user authenticates with the single sign-on provider using their email address and a password (optionally with multi-factor authentication).
    2. If the device does not provide risk assessment information (through Portnox AgentP or Intune/Jamf integration), the user cannot access the application.
    3. If the device does not have the Portnox security certificate (distributed by AgentP or obtained through Intune/Jamf using the SCEP protocol), the user cannot access the application.
    4. If the user meets the above conditions, but the risk assesment engine (AgentP or Intune/Jamf) discovers that certain conditions are not met, the administrator may prevent the user from accessing the application. For example:
      • If the device has an outdated version of the operating system
      • If the device has no antivirus software installed
      • If the user is currently located outside United States

How does ZTNA conditional access work?

If your application is integrated with ZTNA through conditional access, here is what happens when an example user tries to access the application.

From the user’s point of view, the process is almost identical to the one when the user logs in using single sign-on such as Azure or Google.

  1. The user types the address of the web application in their browser to access it, just like they would without ZTNA.

  2. The user either clicks or taps on the button to log in using ZTNA or simply enters their email address (this depends on the application).

  3. The application automatically redirects the browser to Portnox Cloud, which checks if the user’s device has a Portnox security certificate. If the device is certified, Portnox Cloud redirects the browser to an identity provider such as Microsoft Entra ID (Azure Active Directory), Google Workspace, or other. The identity provider is configured in Portnox Cloud for the specific application.

  4. The identity provider handles user authentication. For example, the user may enter their email address and password, provide multi-factor authentication using an authenticator app, or use any other authentication method supported by the identity provider. Once the user is authenticated, the identity provider redirects the browser back to Portnox Cloud.

  5. Now that Portnox Cloud knows the application, knows that the device is certified, and knows the logged in user, it communicates with Portnox AgentP installed on the user’s device or the Intune/Jamf agent/engine. It then checks the policies configured in Portnox Cloud or in Intune/Jamf for the application or for a specific group of users. These policies may include operating system versions, installed software, location, and more. Based on these policies, either AgentP or Intune/Jamf decides if the device is safe for application access or not, and sends that information to Portnox Cloud.

  6. Portnox Cloud either redirects the user back to the application after a successful login, or informs the user that they cannot be logged in because their device is not safe. Optionally, Portnox Cloud can redirect the user to the company’s support pages, software download pages, or simply display a custom message configured by the administrator.

What do you need to be able to use ZTNA conditional access?

To be able to use Portnox ZTNA conditional access, you need to meet the following conditions.

  • You need to buy a Portnox ZTNA license. Without a license, you can test ZTNA conditional access for one application only.

  • You need to have a configured cloud-based authentication repository such as Microsoft Entra Id (Azure Active Directory) or Google Workspace. Portnox Cloud must work together with your authentication repository to know the users accessing your applications.

  • You need to have an identity provider that supports the Security Assertion Markup Language (SAML) protocol. Such identity providers are offered by most authentication repositories (including Entra ID and Google Workspace) but you can also use third-party identity providers that work together with your authentication repository.

  • You need to have an option to configure a SAML-based single sign-on (SSO) integration in your resource (web application or service). Most enterprise applications and services have such capabilities.

  • Your users need to have Portnox AgentP installed on all their devices, even their BYOD/personal devices, or these devices must be enrolled in Intune/Jamf, and Portnox Cloud must then be integrated with Intune/Jamf:

    • You can distribute AgentP using your endpoint management solutions such as Intune, or you can ask your users to install AgentP manually. If you want to ask your users to install AgentP manually, such as on BYOD (bring your own device) devices, you can give them the following link: https://docs.portnox.com/byod/. This link contains end-user instructions for all popular desktop/mobile operating systems: Windows, macOS, iOS, and Android.

    • If you prefer not to use AgentP, you must integrate Portnox Cloud with Intune or Jamf, and you must configure Intune/Jamf so that enrolled devices request Portnox Cloud certificates using the SCEP protocol (see: Automatic onboarding with endpoint management.

How is the integration with ZTNA conditional access configured?

For ZTNA conditional access to work, Portnox Cloud needs to be integrated with at least one identity provider and with at least one application.

Both integrations are very similar and do not involve any coding or any external components. Integration happens by exchanging a set of single sign-on (SSO) identifiers and URLs. To integrate with an identity provider or with an application, you simply need to copy some values from the configuration screen of one product and paste them into the right fields on a configuration screen of the other product.

ZTNA conditional access supports a globally recognized mechanism for single sign-on integration: Security Assertion Markup Language (SAML). We are working on supporting other mechanisms such as OpenID.

Integrating with an identity provider

When you integrate ZTNA conditional access with an identity provider, you must create a custom SAML app in the identity provider configuration, and then copy at least the following values from the Portnox Cloud configuration screen to a custom SAML app configuration screen:

  • The Portnox Cloud identifier that it generated for the identity provider, so that Cloud can recognize and trust the communication
  • The Portnox Cloud URL to which the identity provider is supposed to send the user after successfully authenticating them

You must also copy at least the following values from the identity provider’s custom SAML app configuration screen to the Portnox Cloud configuration screen:

  • The identity provider’s URL to which Portnox Cloud is supposed to redirect users for authentication
  • The identity provider’s identifier used in its single sign-on tokens
  • The identity provider’s security certificate, so that Portnox Cloud can verify that it’s communicating with the identity provider and not an intruder

Integrating with a web application

When you integrate a web application with ZTNA conditional access, you must copy at least the following values from the Portnox Cloud configuration screen to the application configuration screen:

  • The Portnox Cloud identifier that the application is supposed to use during communication, so that Cloud can recognize and trust the incoming authentication requests
  • The Portnox Cloud URL to which the application is supposed to redirect the user for authentication
  • The Portnox Cloud security certificate, so that the application can verify that it’s communicating with Portnox and not an intruder

You must also copy at least the following values from the application configuration screen to the Portnox Cloud configuration screen:

  • The application’s unique identifier, so that Portnox Cloud can identify it during communication
  • The application’s URL to which Portnox Cloud is supposed to redirect the user after successfully authenticating them

What resources are supported by ZTNA conditional access?

ZTNA conditional access works with all resources that support SP-initiated SAML flow.

In the left-hand side menu, you can see a list of resources that we tested and confirmed to work with ZTNA conditional access. This list will grow with more resources that we are able to test either internally or together with our customers.

Note: We found a few resources that support SAML SSO but must be configured manually by their support staff:

ZTNA remote private access

In this topic, you will learn what is the remote private access method in Portnox™ Zero Trust Network Access and how it works.

The ZTNA remote private access service provides secure user access to private resources (applications and services), removing the need for VPNs when they are only used to access such applications.

A private resource is a web application or service that is not publicly accessible. It can be hosted on-premises or in a secure cloud instance and is meant only for specific people, such as employees, students, or contractors who have been explicitly given access. With the rise of remote work, these resources are often accessed by remote employees, requiring a secure connection over possibly insecure internet networks.

Traditionally, VPNs have been used to create secure connections. However, VPNs are often hard to manage and do not have modern security features like multi-factor authentication, certificate-based authentication, and real-time risk assessment. They may also need special hardware for on-premises deployments.

ZTNA remote private access provides a simpler and more cost-effective way to access secure resources. The only requirement is to set up a Docker container or a container instance in a network that has a direct connection to the resources, such as a local network or a virtual network in the cloud.

One key advantage of Portnox ZTNA remote private access is its ability to adapt to changes in the security status of devices accessing private resources. By integrating with your UEM solution, such as Intune, or using Portnox AgentP to manage configuration and monitor device risk levels, you can instantly revoke access if a device goes above a set security limit. For example, if a user removes antivirus software, Portnox Cloud can be set to automatically block access to private resources from that device until the issue is fixed.

How does ZTNA remote private access work?

If your resource is integrated with ZTNA remote private access, here is what happens when an example user tries to access the resource.

For the user, the process is almost the same as logging into a public resource.

  1. The user types the address (URL) of the resource in their browser to access it. Depending on how the organization’s administrator sets up Portnox Cloud, this URL can be in the customer’s domain (for example, https://resource.vorlon.com) or in the portnox.com domain (for example, https://resource.us.portnox.com).

    Note: To use your own domain, the organization administrator must add a canonical name record to the organization’s DNS server, and upload a TLS certificate (for that subdomain or wildcard) with the corresponding private key to Portnox Cloud.

  2. The user is then connected to Portnox Cloud. Cloud checks for the user’s certificate in the browser’s underlying operating system, and uses this certificate to securely authenticate the user.

  3. Portnox Cloud then creates a secure tunnel within the browser, which connects the user to the private resource without any extra steps needed.

    Note: The secure tunnel first connects Portnox Cloud with the Docker container in your resource’s local network, and then connects the Docker container with the resource. The entire connection is fully encrypted and highly secure.

What do you need to be able to use ZTNA remote private access?

To be able to use ZTNA remote private access, you need to meet the following conditions.

  1. License

    • You need to buy a Portnox ZTNA license.

  2. Authentication repository

    • You need to set up a cloud-based authentication repository, such as Microsoft Entra ID (Azure AD) or Google Workspace. Portnox Cloud connects with your authentication repository to authenticate users accessing your private resources.

    • If you do not use an external repository, you can use Portnox Cloud’s internal repository to manage users.

  3. Docker container

    • You need to deploy a Portnox Docker container in a network that has direct access to your private resources, for example, the same local network where you host your private resources. You can run the container on physical or virtual machines using any operating system supported by Docker, including Linux, Windows, or macOS.

    • If your private resources are hosted in the cloud, you can deploy the container in services like Azure, AWS, or Google Cloud.

    • The Docker container needs to be able to communicate with the Internet on ports TCP 443 and UDP 3478.

  4. Certificates

    • You need to install user or device certificates on all devices that need access to the private resources.

    • You can install certificates using Portnox AgentP. You can also install them by having Intune or Jamf trigger a request for the certificate from the device to the Portnox SCEP service.

  5. Optional: custom domain configuration

    To use a custom URL in your organization’s domain:

    • You need to add a canonical name (CNAME) record to your domain’s zone on your DNS server.

    • You need to obtain a TLS certificate with a private key for this URL or use an existing wildcard certificate, and upload this certificate to Portnox Cloud.

How is the integration with ZTNA remote private access configured?

For ZTNA remote private access to work, you need to create at least one gateway and at least one resource entry in Portnox Cloud, and you need to run the Docker container in a network with direct access to your private resources.

Creating a gateway entry in Portnox Cloud

  1. You need to choose where the Portnox end of the gateway is located. Portnox Cloud provides three locations: two US-based and one EMEA-based. You can choose the location depending on where you host your resources, but the performance of Portnox Cloud is excellent with both locations. If your resources are hosted outside US/EMEA, you can use either location without any noticeable performance losses.

  2. You need to install Docker on a physical or virtual machine in a network that has direct access to your private resource. If you host your private resources in a cloud such as Azure, AWS, or Google Cloud, you need to use the provider’s mechanism to create a Docker instance in its virtual network, for example, Azure container instances.

  3. You need to create a Docker container by running a command provided by Portnox Cloud. This makes it very easy to create the container correctly, even if your knowledge of Docker is very limited.

Creating an resource entry in Portnox Cloud

  • You need to choose which gateway the resource works with.

  • You need to choose if you want to use a Portnox URL for the resource, or a URL in your organization’s domain:

    • If you want to use a portnox.com URL, this URL will be either: resource_name.us.portnox.com, if your resource is connected to the US-based gateway, or resource_name.eu.portnox.com, if your resource is connected to the EMEA-based gateway.

      Note: Make sure to check if your web resource will accept connections when accessed using this URL. If your web security solution has an anti-CSRF feature, you will need to configure it to allow this URL.
    • If you want to use your organization’s URL, for example, https://resource.vorlon.com, you need to upload a certificate and a private key obtained from a certification authority for resource.vorlon.com (or a wildcard certificate for *.vorlon.com), and you need to add a canonical name (CNAME) record to your DNS server’s zone, for example: 
      resource.vorlon.com. IN CNAME resource.us.portnox.com.

  • You need to supply the IP address and port of the private resource, which must be accessible from the Docker container. For example, if you use a Class A (10.0.0.0/16) network, you can have your Docker container running at 10.250.0.10, and you can have your resource running on a web server at 10.1.9.57, on port 443, using the HTTPS protocol.

  • If your resource runs on the same IP address and port number as other resources, you need to provide the Host HTTP header value that will be sent to the web server to open the correct resource.