Today’s ZTNA is not enough for diverse applications

Authentication & Authorization comes in various colors

The Zero Trust Network Access (ZTNA) component of SASE is designed to provide secure inbound access to enterprise private applications. In line with the core principle of identity-based access control in Zero Trust Architecture (ZTA), ZTNA plays a vital role in authenticating users and enforcing access controls based on user types, groups, and roles on every inbound session to the Enterprise applications.

ZTNA security offers significant advantages in the following scenarios:

• Legacy Applications: Legacy applications that lack built-in security measures are often not exposed to Work-From-Anywhere (WFA) users due to security concerns. By utilizing ZTNA to front-end these legacy applications, HTTPS termination with certificate management, authentication using protocols such as OIDC, and authorization based on context-aware access controls can be provided. This enables legacy applications to be safely accessed by WFA users over the Internet.
• Broken Applications: Despite being developed with security in mind, some applications may not have been updated for an extended period. These applications may lack proper certificate management, with outdated or no support for uploading new certificates or auto-renewal. ZTNA can act as a security replacement for these broken applications, ensuring secure access while overcoming their security limitations.
• New Application Architecture: Modern enterprise applications are often designed with security considerations shifted to external entities like ZTNA and service mesh technologies. This approach relieves application developers from the burden of handling HTTPS, authentication, and authorization, as security is offloaded to the front-end entity. By centralizing security management, benefits such as uniform security policy enforcement, increased productivity in application development, and simplified maintenance are achieved. Additionally, as security updates are handled externally, the frequency of patch releases aimed at addressing security issues can be significantly reduced.

Many ZTNA solutions today are good at front-ending simple Enterprise applications, but they fail to deliver to provide authentication & authorization for multi-tenant applications such as SaaS applications.

ZTNA’s Role in SaaS Applications: In the context of Software-as-a-Service (SaaS) applications, ZTNA will play a vital role in strengthening and enhancing the authentication and authorization mechanisms, in my view. SaaS applications have specific requirements, including multi-tenancy, resilience against DoS/DDoS attacks, and robust protection against authentication bypass and privilege escalation attacks. This article will delve into the features of next-generation ZTNA that can assist in offloading or enhancing the authentication and authorization processes for SaaS applications. Please note that this article will not cover other features of ZTNA, such as WAAP (Web Application and API Protection), HTTPS termination, traffic management of incoming sessions to various application instances, webification of SSH/RDP/VNC services, and making applications invisible from port scanners. Its primary focus is on the authentication and authorization aspects of ZTNA.

It’s important to note that there can be confusion between the roles of CASB (Cloud Access Security Broker) and ZTNA in the context of SaaS. The CASB component of SASE focuses on securing connections to SaaS services used by enterprises, where enterprises are consumers of SaaS and CASB services. On the other hand, ZTNA, in the context of SaaS, is designed to protect the SaaS application itself, making SaaS companies consumers of ZTNA services. This differentiation is essential to understand the distinct roles and responsibilities of CASB and ZTNA in the SASE solutions.

In a previous article about identity brokers, we explored the numerous benefits of integrating brokers into SASE solutions. The advantages discussed primarily revolved around the modularity and simplicity of design, ultimately enhancing the resilience of SASE solutions. In this article, we will delve into the pivotal role of identity brokers in supporting complex applications, particularly focusing on SaaS applications.

What are the challenges with multi-tenant applications?

ZTNA of SASE excels in providing robust support for policy-based authorization. The authorization engines within SASE offer the capability to manage multiple policy tables, with each table containing multiple policies. Each policy is composed of multiple rules and specifies the action to be taken upon a successful match. The rules themselves encompass various matching attributes, which can be classified as source and destination attributes.

Destination attributes primarily pertain to the applications’ resources being accessed, such as URIs and the methods (e.g., GET, PUT, POST, DELETE) used to interact with those resources. On the other hand, source attributes are typically associated with the subjects accessing the resources. These attributes encompass user-related attributes like name, group, role, authentication service that validated the user credentials, and other user claims. They also include device context attributes, which capture the secure posture of the devices utilized by the subject and the location of the device from which the user is accessing the resources.

However, many ZTNA solutions fall short when it comes to addressing comprehensive authentication scenarios, often limiting their capabilities to non-SaaS applications. The inclusion of an Identity Broker in SASE/SSE solutions is a progressive step towards achieving comprehensive authentication across all types of applications. While it may be argued that SaaS vendors possess the capability to handle authentication and authorization within their applications, the landscape has evolved significantly.

In today’s agile environment, SaaS providers increasingly recognize the advantages of offloading security responsibilities to external entities like SASE. By doing so, they can benefit from increased productivity and heightened confidence in their overall security posture. Furthermore, this approach allows new SaaS providers to enter the market more swiftly, as they can offload authentication and authorization to an external entity and focus primarily on their core business logic. SASE solutions can play a pivotal role in supporting these new SaaS providers.

It is our belief that SASE solutions should and will be ready to take up this challenge of providing authentication and authorization security on behalf of complex applications such as SaaS applications. The following scenario gives one representative example of a SaaS application and explores how SASE, by integrating identity brokers, can help in the delegation of authentication & authorization from the applications.

Consider this example SaaS application (hosted at app.example.com) scenario consisting of multiple API resources:

In this scenario, let’s also assume that the IDP for the SaaS provider is example-idp.

There are two tenants: XYZ and ABC, with their respective IDP services being XYZ-idp and ABC-idp. Each tenant also has two partners, each with their own IDP service. XYZ-P1-idp and XYZ-P2-idp are IDP services of XYZ partners. ABC-P1-idp and ABC-P2-idp are IDP services of ABC partners.

Furthermore, XYZ tenant requires authentication via Google and Facebook for access to the public API space, while ABC tenant prefers authentication through LinkedIn and GitHub.

The following authorization policies are needed in ZTNA to address the above scenario:

1. Domain = app.example.com; user-role=app-admin; authservice=example-idp; uri = /service-admin-api/* ALLOW: Allow access to any user who has successfully logged in to the example-idp service and possesses the app-admin role for all resources under the admin-api of the application with the domain app.example.com.
2. Domain = app.example.com; user-group=admin-group; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-admin-api/* ALLOW: Allow access to any user who has successfully logged in to the XYZ-idp service possessing the admin-group role for all resources under the XYZ/tenant-admin-api.
3. Domain = app.example.com; user-role=admin-role; authservice=ABC-idp; uri = /tenants/ABC/tenant-admin-api/* ALLOW: Allow access to any user with the admin-role, authenticated with the ABC-idp service, accessing the ABC/tenant-admin-api resources
4. Domain = app.example.com; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-user-api/*, /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Allow access to resources specified in the rule for any user that was successfully authenticated with XYZ-idp service
5. Domain = app.example.com; authservice=ABC-idp; uri = /tenants/ABC/tenant-user-api/*, /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Allow access to resources specified in the rule for any user that was successfully authenticated with ABC-idp service
6. Domain = app.example.com; authservice=XYZ-P1-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Allow access to XYZ collaboration space for users authenticated with XYZ-P1-idp service.
7. Domain = app.example.com; authservice=XYZ-P2-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Allow access to XYZ collaboration space for users authenticated with XYZ-P2-idp service.
8. Domain = app.example.com; authservice=ABC-P1-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Allow access to ABC collaboration space for users authenticated with ABC-P1-idp service.
9. Domain = app.example.com; authservice=ABC-P2-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Allow access to ABC collaboration space for users authenticated with ABC-P2-idp service.
10. Domain = app.example.com; authservice=google.com; uri = /tenants/XYZ/public-api/* ALLOW: Allow access to XYZ public-api space for all users authenticated with google.com.
11. Domain = app.example.com; authservice=facebook.com; uri = /tenants/XYZ/public-api/* ALLOW: Allow access to XYZ public-api space for all users authenticated with facebook.com
12. Domain = app.example.com; authservice=linkedin.com; uri = /tenants/ABC/public-api/* ALLOW: Allow access to ABC public-api space for all users authenticated with linkedin.com
13. Domain = app.example.com; authservice=github.com; uri = /tenants/ABC/public-api/* ALLOW: Allow access to XYZ public-api space for all users authenticated with github.com
14. Domain = app.example.com; DENY: Deny access to the application if none of the above rules match.

SASE solutions excel at attribute-based access control. This means that they handle authorization functionality well. However, they are not very comprehensive when it comes to authentication. In the policies above, different levels of access are granted based on the identity provider (IDP) service that users choose to authenticate with. Also, some users may deliberately want to authenticate with a specific IDP service to access resources with minimal permissions to avoid potential data exfiltration mistakes.

Role of Identity Brokers

To address such scenarios, the integrated functionality of an identity broker is required. Identity brokers serve as OIDC (OpenID Connect) providers to the SASE/SSE proxy component while acting as OIDC/SAML/LDAP clients to the upstream identity services (authentication services).

Keycloak, an open-source IAM system, is a popular choice for many. It can be configured to fulfill the role of an identity broker and is commonly used by SASE service providers and service mesh product vendors. Hence, Keycloak terminology is used here. Keycloak offers the flexibility to handle authentication for various types of applications, including multi-tenant SaaS applications.

Authentication for multi-tenant SaaS applications can be achieved using ‘identity brokers’ in the following manner:

One realm with one client for each SaaS application with modified authentication flows:

In cases where the application-tenant cannot be identified from the URL path or HTTP request headers, the SASE proxy component can have only one OIDC client to communicate with the identity broker. During user authentication, the identity broker needs to know which IDP service to authenticate the user against. Keycloak provides standard authentication flows such as browser flow and allows the creation of customized flows and associates with Keycloak clients. SASE leverages this feature by creating authentication flows where users are prompted to provide tenant information. Based on this information, the authentication flows can present the available identity providers for the user to select from. With this information, the broker can redirect users to the appropriate identity service.

One realm with multiple clients for each SaaS application:

If the application-tenant can be identified from the URL or HTTP request headers, the SASE proxy component can be configured to use one client for each application-tenant. In this case, standard browser flows with different sets of identity providers can be employed and associated with the corresponding client entities in Keycloak. The advantage of this is that the user is not prompted to give the tenant name, hence better user experience.

In summary, these strategies empower SASE solutions to effectively handle authentication for multi-tenant SaaS applications, leveraging the capabilities of Keycloak as an identity broker.

Policy-based OIDC Client Selection

The Keycloak broker offers support for multiple realms and multiple clients within each realm. It enables standard authentication flows, the creation of custom authentication flows, and the association of these flows with clients. The Keycloak broker functionality also allows for the brokering of authentication sessions between user-side authentication mechanisms and backend (upstream) authentication services. We have previously discussed how Keycloak can prompt users to identify their application-tenant and select the identity service for authentication.

These capabilities should also be leveraged by the SASE proxy, which acts as an OIDC client (also known as OIDC relay) for various customer applications, including multi-tenant applications.

The SASE proxy needs to support multiple OIDC clients. One approach is to have a set of OIDC clients for each customer, ensuring that customer-specific authentication-related configurations are isolated from others. Typically, each SASE customer’s OIDC set is associated with a realm in Keycloak.

In scenarios where a customer of the SASE proxy has multiple applications, each with its own domain name, it becomes necessary to provide isolation among multiple application administrators. In such cases, a subset of OIDC clients should be configured, with one client assigned to each application.

For many applications, a single OIDC client suffices if they are single-tenant application or if the tenant cannot be identified from the traffic, as discussed earlier. However, if the tenant can be identified, one OIDC client can be configured for each application-tenant.

Due to the requirement for multiple OIDC clients, the SASE proxy should offer a mechanism for selecting the appropriate OIDC client. This is where policy-based OIDC selection becomes crucial.

A policy table with multiple policies is utilized, with each policy pointing to the corresponding OIDC client record. During the traffic flow, the SASE proxy checks whether OIDC authentication is required and then matches the customer, application domain name, and application-tenant against the policies in the table. If a match is found, the corresponding OIDC client record is used to communicate with the broker. Some implementations may have multiple policy tables, with one table dedicated to each customer, to expedite the policy matching process.

NextGen ZTNA will adapt to multi-tenant applications

ZTNA (Zero Trust Network Access) within SASE (Secure Access Service Edge) solutions play a crucial role in securing applications. It enables the offloading of authentication and authorization tasks from applications, allowing developers to focus on their core business logic. This approach enhances productivity and bolsters overall security.

Authentication bypass and privilege escalation vulnerabilities are common in applications, as not all developers have expertise in security. Offloading security can eliminate these vulnerabilities, ensuring stronger application resiliency.

Centralizing security in a commonplace, such as SASE, simplifies the work of security administrators, who only need to manage a single interface for all applications.

To achieve both security and flexibility, the next generation of ZTNA within SASE solutions should address diverse application types. Many existing ZTNA solutions often struggle to support multi-tenant applications effectively. Future enhancements are expected to incorporate identity broker functionality and policy-based OIDC (OpenID Connect) client selection to cater to a wide range of application scenarios.

• CTO Insights blog

  The Aryaka CTO Insights blog series provides thought leadership for network, security, and SASE topics. For Aryaka product specifications refer to Aryaka Datasheets.