The Secure Access Service Edge (SASE) service, along with its associated architecture, comprises a powerful amalgamation of multiple security components. These include a stateful inspection firewall, Intrusion Detection and Prevention System (IDPS), DNS security, DoS/DDoS protection, Secure Web Gateway (SWG), Zero Trust Network Architecture (ZTNA), Cloud Access Security Broker (CASB), and many more. These components grant administrators the ability to configure them through policies, offering a robust shield to protect an organization’s assets against threats while adhering to specific access requirements.

The Role of Policy Configuration

Policy configuration plays an indispensable role in enforcing security within the SASE framework. The repercussions of badly configured policies can range from resource threats and data leaks to unintended, overly permissive access. In today’s industry landscape, organizations grapple with two predominant approaches to security policy management:

1. The Single Table Approach: A consolidated policy table containing a myriad of policies that span threat management and various access control scenarios across all SASE components.
2. The Multi-Table Approach: Multiple policy tables, each addressing specific aspects such as threat protection, access control, different applications, and user groups.

Striking a Balance in Policy Management

The expectation from SASE is clear: it should offer easily manageable security policies and simplified troubleshooting procedures. Achieving this necessitates a balanced approach. One effective strategy to mitigate policy complexity based on organizations requirements. Bigger organizations may require compartmentalization with multi-Table approach where policy table granularity is defined based on security functions, application resources, and subject (users/groups). Smaller organizations may prefer compartmentalization with a lesser number of policy tables combining multiple types of access controls or even combining threat protection with access control. This flexible approach minimizes the number of policies requiring simultaneous management, rendering them more manageable.

However, it’s important to exercise caution to avoid excessive compartmentalization, which can introduce its own set of challenges. Administrators may find themselves navigating through multiple policy tables to identify and address issues, potentially causing delays in resolution.

Understanding the Key Requirements

Before delving deeper into the intricacies of policy management, it’s crucial to understand the specific requirements that organizations must address within the SASE framework. Key areas include:

Need for Role-Based Security Configuration Management in SASE Environments

Secure Access Service Edge (SASE) components offer comprehensive security, encompassing threat protection and access control for a wide range of resources across diverse organizations, including their workforce, partners, and guests. Within this security framework, organizations often have distinct categories of administrators responsible for different aspects of security.

For example, an organization may have one group of administrators dedicated to managing threat protection while another group focuses on access controls. Within these broad categories, it’s common for organizations to establish various administrative roles tailored to specific types of threat protection and access control. Let’s delve into some practical examples:

Threat Protection Roles:

• Intrusion Detection and Firewall Configuration: Administrators with the “threat-protection-ngfw-role” are granted access to configure Intrusion Detection and firewall settings within the SASE environment.
• Reputation Controls: Administrators holding the “threat-protection-reputation-role” can manage settings related to IP reputation controls, URL-based reputation controls, domain-based reputation controls, file reputation controls, as well as cloud-service and cloud-organization reputation controls.
• Malware Protection: Administrators with the “threat-protection-malware-protection-role” have the authority to configure settings specifically pertaining to malware protection controls.

Access Control Roles:

• SWG Configuration: Administrators designated as “access-control-Internet-role” are responsible for managing Secure Web Gateway (SWG) configurations.
• SaaS Application-Specific Access Control: Roles like “access-control-saas1app-role” and “access-control-saasNapp-role” focus on configuring access control policies for specific applications (SaaS Service 1 and SaaS Service N), ensuring fine-grained control.
• Enterprise Application Management: Roles such as “access-control-hostedapp1-role” and “access-control-hostedappM-role” are dedicated to handling access control configurations for enterprise-level applications, app1 and appM.

In cases where an organization uses multi-tenant applications, additional roles may be introduced to manage security configurations effectively. For instance, roles can be established to configure policies for the organization’s workforce, per-tenant workforce, and even guests. Consider an application “X” with security configurations managed by different sets of administrators:

• Owner Workforce Security: Administrators with “access-control-hostedappX-role” and “access-control-owner-workforce-role” collaborate to manage access control configurations for application “X” for the owner’s workforce.
• Application Tenant-Specific Workforce for Tenant: Roles like “access-control-hostedAppX-role” and “access-control-owner-tenantA-workforce-role” enable administrators to configure access control settings for tenant A’s workforce.
• Application Tenant specific workforce for Tenant B: For a multi-tenant application “X,” various roles, such as “access-control-hostedAppX-role” and “access-control-owner-tenantB-workforce-role,” facilitate the management of access control configurations for tenant B’s workforce.

Additionally, even non-multi-tenant enterprise applications may require separate administrators for different workforce segments. For instance:

• Engineering Department: Administrators with “access-control-hostedappY-role” and “access-control-eng-role” focus on managing access control configurations for application “Y” within the engineering department.
• Sales & Marketing: Roles like “access-control-hostedappY-role” and “access-control-sales-role” are designated for configuring access control settings for sales and marketing teams.
• IT Department: Administrators with “access-control-hostedappY-role” and “access-control-it-role” have responsibilities for access control configurations pertaining to the IT department.

A significant advantage of role-based security configuration management is its ability to provide granular control tailored to specific responsibilities. Contrast this approach with the challenges that can arise when using a single, all-encompassing policy table:

• Error-Prone: Multiple administrators working with the same policy table and overlapping permissions may inadvertently introduce errors when adding, deleting, or modifying policies.
• Troubleshooting Complexity: Resolving issues within a monolithic policy table can be time-consuming and challenging.
• Policy Overload: Consolidating all policies into a single table, covering various applications and threat protection scenarios, can lead to a cumbersome and unwieldy policy management experience, as well as potential performance challenges during policy evaluation.

In conclusion, adopting role-based security configuration management within SASE environments empowers organizations to efficiently delegate responsibilities, enhance security, and streamline policy management while avoiding the complexities associated with single-table approaches.

Working alongside with Configuration Change Control Management

Organizations are increasingly embracing change control management for all configurations, including SASE configuration, to proactively detect and rectify configuration errors before they are implemented. This practice not only serves as a safeguard but also introduces a secondary layer of scrutiny, allowing a second set of eyes to review and approve configurations before they take effect.

Security policy configurations are applied directly within the traffic flow, making any errors in policies potentially disruptive to services and incurring direct financial consequences.

To cope with the inherent complexity of security policy configuration, it’s common practice to serialize changes. This means that when modifying one type of configuration, no other configuration sessions of the same type are initiated until the previous one is either applied or revoked. However, when using a single policy table that encompasses all threat and access control functions, serializing changes can introduce delays in configuration adjustments performed by other administrators.

In contrast, a multi-table approach can effectively address this scenario, allowing different administrators to concurrently work on distinct tables, thus streamlining the configuration change process.

Not all organizations share the same requirements:

SASE is typically offered as a service, and SASE providers may serve multiple organizations as customers. These organizations can vary significantly in terms of size, regulatory requirements, and the diversity of roles within their structures. Some organizations might host multiple applications, either On-Premises or in the cloud, while others may exclusively rely on services from SaaS providers, and some may incorporate a combination of both.

Furthermore, certain organizations may not have a need for various administrative roles or multiple administrative users. In scenarios where organizations have only a limited number of applications and lack the complexity of multiple administrative roles, they may find value in using fewer policy tables.

SASE is expected to be designed to offer the flexibility required to accommodate these diverse needs, including the option of using consolidated policy tables for multiple relevant security functions and applications.

Avoiding confusing configurations:

Certain SASE solutions, in their pursuit of simplification as discussed before, opt for a single, all-encompassing policy table where policies can be configured with values for various matching attributes. During traffic processing, policy selection is based on matching the values from the incoming traffic and other contextual information against the attribute values specified in the policies.

However, it’s crucial to recognize that during traffic processing, not all attributes of the traffic are readily known. For instance, in the case of stateful inspection firewalls, only a limited set of traffic values can be extracted, such as the 5-tuple information (source IP, destination IP, source port, destination port, and IP protocol). Meanwhile, for proxy-based security components like SWG, ZTNA, and CASB, the extraction of attribute values can vary and may involve distinct stages, notably the Pre-TLS inspection and Post-TLS inspection phases.

Before TLS inspection/decryption, many HTTP attributes remain unknown. It’s only after TLS decryption that additional attributes, such as access URI path, HTTP method, and request headers, become available for evaluation.

As administrators responsible for configuring security policies, it is impractical to expect administrators to keep track of which attributes are valid at various stages of packet processing while defining policies. While some security solutions claim that irrelevant attributes are not considered in policy evaluation, determining which attributes are pertinent and which are not can be challenging when inspecting complex policies.

We firmly believe that amalgamating policy tables across multiple stages into a single table creates complexity and confusion for administrators. Such an approach can be challenging to comprehend and lead to potentially perplexing configurations. To ensure clarity, it is advisable to create policies within a given table that include only relevant attributes for consistent and straightforward evaluations.

Optimizing Deny and Allow Policy Tables:

Certain security solutions adopt a structure where they maintain separate “Deny” and “Allow” policy tables. Within this setup, policies defined in the “Deny” list take precedence and are evaluated first. If no matching policy is found in the “Deny” table, the evaluation proceeds to the “Allow” policy table. However, this division of policies into two distinct tables can pose challenges for administrators.

We firmly advocate for a more streamlined approach, where any given policy table is presented as an ordered list of policies. In this arrangement, each policy explicitly specifies its action—whether it’s “Deny,” “Allow,” or any other desired action. During traffic processing, policy evaluation follows a logical progression from the highest priority policy to the lowest priority policy until a match is found. Once a matching policy is identified, the corresponding action is applied to the traffic. In cases where no matching policy is encountered, a default action, such as “fail open” or “fail close,” is triggered as defined by the organization’s security policy.

This approach simplifies policy management and enhances clarity for administrators by consolidating policies within a single and ordered list irrespective of the policy action values, thereby minimizing complexity and streamlining the policy evaluation process. Not separating policy tables based on action values also enabled SASE solution providers to introduce new action values in future relatively easily.

Creating Flexible and Expressive Policies:

As you’ve gathered, administrators craft policies by defining sets of values for matching attributes. Traditionally, there has been a common understanding of how policy matching operates during traffic evaluations: a policy is considered a match only when all the attribute values specified in the policy align perfectly with the values of the incoming traffic session. These values can either be extracted directly from the traffic or inferred from contextual information, such as the authenticated user context and the device context responsible for initiating the traffic. Essentially, this matching process involves an ‘AND’ operation across all attributes of the policy.

However, as security technologies have evolved, many security devices have introduced a more flexible approach, granting administrators the ability to assign multiple values to attributes. In this evolved paradigm, a match is established if the runtime context information aligns with any of the values specified for the policy attributes. In essence, the matching process now combines an ‘AND’ operation across attributes with an ‘OR’ operation across the values associated with those attributes.

Organizations stand to benefit significantly from this flexibility when creating comprehensive policies. It reduces the overall number of policies required while maintaining readability. However, these multi-value attributes are just one step in the right direction, and further enhancements are often necessary to meet organizations’ unique requirements:

Support for “NOT” Decoration: Administrators require the ability to define policy attribute values with a “NOT” decoration. For instance, it should be possible to specify a ‘source IP’ attribute value as ‘NOT 10.1.5.0/24,” indicating that the policy will match successfully when the traffic session’s source IP does not belong to the 10.1.5.0/24 subnet.

Support for Multiple Instances of an Attribute: Many traditional security devices support only one instance of a given attribute within a policy. To create comprehensive policies, the ability to include multiple instances of the same attribute within a single policy is essential. For example, an administrator may want to allow sessions from any IP address in the 10.0.0.0/8 subnet while simultaneously denying traffic sessions from the 10.1.5.0/24 subnet. This should be achievable within a single policy, perhaps by specifying ‘source IP’ values twice: “source IP == 10.0.0.0/8” and “source IP == NOT 10.1.5.0/24.” This prevents the need to create two separate policies and allows for more intuitive policy management.

Support for Decorations for String Type Values: Attributes that accept string values, such as URI paths, domain names, and many HTTP request headers, benefit from decorations like ‘exact,’ ‘starts_with,’ and ‘ends_with.’ These decorations enhance the creation of expressive policies.

Support for Regular Expression Patterns: In some cases, policies require pattern matching within traffic values. For instance, a policy may dictate that a traffic session is allowed only if a specific pattern is present anywhere in the ‘user agent’ request header value. Support for regular expression patterns is essential in such scenarios.

Support for Dynamic Attributes: While traditional attributes in policies are fixed and predefined, SASE environments sometimes require dynamic attributes. Consider request and response headers or JWT claims, where standards coexist with numerous custom headers and claims. SASE should empower administrators to create policies that accommodate custom headers and claims. For example, SASE should allow the creation of policies with the request header ‘X-custom-header’ as an attribute and the value ‘matchme.’ At traffic time, any HTTP sessions with ‘X-custom-header’ as one of the request headers and ‘matchme’ as the value should match the policy.

Support for Objects: This feature allows the creation of various types of objects with values that can be used as attribute values in policies, rather than specifying immediate values. Objects can be referenced across multiple policies, and any future value changes can be made at the object level, simplifying policy modifications, and ensuring consistency.

These enhancements contribute to the creation of flexible, expressive, and efficient security policies, empowering organizations to tailor their policies to unique security needs and scenarios effectively.

Enhancing Policy Integration with traffic modifications

Certain security functions necessitate modifications to traffic, with the most common use cases involving the addition, deletion, or modification of HTTP request/response headers and their values, query parameters and their values, and even the request/response body. These modifications can vary significantly based on administrators’ configurations. Often, the specific modifications depend on traffic values, such as the destination application/site service, as well as contextual information available during traffic runtime.

Rather than maintaining a separate policy table for traffic modifications, it is often more efficient to include these modification objects within the access policies themselves. This approach streamlines policy management and ensures that modifications are directly aligned with the policies governing traffic behavior.

One prominent scenario where traffic modification is essential is in the context of Cloud Access Security Broker (CASB) solutions, particularly when organizations require multi-tenancy restrictions. These restrictions often involve the addition of specific request headers and values to enforce collaboration-specific policies. Additionally, there are other instances, such as the addition of custom headers for end-to-end troubleshooting and performance analysis, where traffic modifications play a crucial role.

Consequently, organizations expect SASE solutions to support policies that seamlessly integrate with modification objects. During traffic processing, traffic modifications are executed when the matched policy is associated with the appropriate modification objects, providing a unified and efficient approach to traffic management and policy enforcement.

Enhancing Observability:

It is common practice to log every traffic session at the conclusion of the session for the purpose of observability. In cases involving substantial or “elephant” sessions, it is also customary to periodically log access information. These session logs typically contain valuable data, including traffic metadata, actions taken during the session, and details regarding the packets and bytes transferred between the client and server.

One significant advancement offered by SASE is the consolidation of security functions and the adoption of single-pass, run-time-completion architectures, resulting in a unified session log. This contrasts with non-SASE security deployments where each individual security component generates its own session log, often containing information about the policy that was matched and critical attribute values used in the matching process. Importantly, while SASE generates a single log, there is an expectation that it should not compromise on the inclusion of critical information.

When a traffic session is allowed due to multiple policy evaluations across various security functions and policy tables, the resulting log should encompass information about every policy that was matched. Moreover, if a policy matches due to the values of specific traffic or context attributes, the log should provide precise details about the attribute values that led to the policy match.

Given that organizations rely on comprehensive logs for effective observability, SASE solutions are expected to furnish thorough information in the logs, ensuring that administrators have access to the data they need to monitor and analyze network traffic effectively.

SASE Approach to Policy Management:

It’s important to recognize that not all SASE solutions are identical. Organizations should carefully assess whether a particular SASE solution aligns with their specific organizational requirements without sacrificing usability. While organizations may not initially possess all the requirements listed above, it’s only a matter of time before these requirements become increasingly relevant and essential to their operations.

Organizations having all the aforementioned requirements gain the advantage of complete flexibility in tailoring their SASE policies to their specific needs. On the other hand, organizations that do not currently have all these requirements often seek a simpler user experience while keeping an eye on introducing additional functionality as their requirements evolve. This approach allows organizations to strike a balance between their current needs and future growth, ensuring that their SASE solution remains adaptable and responsive to changing circumstances.

Unless SASE solutions provide full flexibility, customization becomes challenging. Therefore, we believe SASE solutions should provide the following core capabilities:

1. Modular Policy Management: SASE solutions encompass multiple security functions, each with its own set of policy configurations. These configurations should include options to enable/disable, set default action in case of no policy match, manage collection of multiple policy tables, define multiple policies within each policy table, establish an ordered list of policies, and set action settings, modification objects, matching attributes, and values for each policy.
2. Policy Chaining: To enable more specific and granular policies, SASE solutions should support policy chaining. This means allowing the arrangement of policies across multiple policy tables in a collection. For example, organizations can have separate policy tables for different applications, with the main table policies using application/domain names as matching criteria to select the appropriate policy tables. This is typically accomplished through the use of policies featuring an action called ‘Jump,’ which redirects policy evaluation to the referenced policy table. The concept of policy chaining gained popularity with Linux IPTables, and many security solutions subsequently incorporated this functionality.

The comprehensiveness of security functions within SASE can be extensive and may include:

• NGFW (Next-Generation Firewall): Providing L3/L4 access control, DDoS protection, IP reputation, domain reputation and, Intrusion Detection and Prevention System (IDPS)
• SWG (Secure Web Gateway): Offering TLS inspection, pre-TLS web access control, post-TLS web access control, URL reputation, file reputation, and malware protection.
• ZTNA (Zero Trust Network Access): Similar to SWG but focused on securing hosted applications.
• CASB (Cloud Access Security Broker): Covering cloud service reputation and cloud service access control.
• DLP (Data Loss Prevention): Implementing access control based on Personally Identifiable Information (PII), standard confidential documents, and enterprise-specific sensitive documents.

The flexibility of policy management for each security function, along with the ability to manage policies within each function via multiple policy tables with policy chaining, is a powerful feature. Geo-distributed organizations with various regulatory requirements can particularly benefit from this flexibility.

However, smaller organizations may prefer some sort of consolidation of policy tables. In such cases, it should be possible to customize the configuration by:

• Consolidating all pre-TLS security function configurations into a single collection of policy tables across multiple SWG/ZTNA components.
• Consolidating all post-TLS security function configurations into another single collection of policy tables across multiple SWG/ZTNA components.
• Retaining CASB, malware, and DLP functions as separate entities as these require complex policy definitions.
• Opting for a single policy table within the policy table collection, thus avoiding policy chaining.

Therefore, organizations should seek SASE services that provide full flexibility while also offering custom controls to consolidate configurations for relevant security functions. This approach ensures that SASE policies are tailored to an organization’s specific needs while maintaining ease of management and scalability as requirements evolve.

Balancing User Experience with Future-Proof Flexibility

Security policy management has historically been a complex endeavor. Many products specialize in policy management for specific security appliances, resulting in a fragmented landscape. SASE addresses this complexity by consolidating multiple security appliances into a unified solution. While this consolidation offers advantages, it also introduces complexities of its own.

Traditional approaches to policy management, such as a single policy table, may seem appealing initially. However, they present numerous challenges and often fall short of meeting the requirements outlined in this article. Conversely, having an excessive number of policy engines can also lead to complexity. Striking the right balance between flexibility and simplicity is paramount.

One significant challenge in the industry is the proliferation of policies. An excessive number of policies not only degrades the user and troubleshooting experience but also carries performance implications. The multi-table approach and policy expressiveness, as described earlier, are essential strategies for reducing the volume of policies within policy tables.

SASE solutions are increasingly addressing these complexities by providing greater sophistication in policy management. It is our belief that SASE solutions will continue to evolve, implementing many of the requirements detailed in this article in the very near future. This evolution will empower organizations to strike the optimal balance between user experience, flexibility, and performance, ensuring that their security policies remain effective and adaptable in a rapidly changing threat landscape.

The post Make Security Simple: Streamline Policies in Unified SASE<h5><i>Balancing Configuration and Control is critical for reducing security risks and management complexity</i></h5> appeared first on Aryaka.

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.

The post Enhancing SaaS Security: Next-Gen ZTNA for Authentication & Authorization appeared first on Aryaka.