The Role of Identify Brokers in a SASE Solution

In my previous blog on identity-aware SASE I discussed zero trust, the role of SASE, and the importance of identity in access controls. Another blog on SASE Proxy explained how SASE solutions obtain users’ identities after authenticating them through Identity Providers (IdPs). To summarize, the forward proxy part of SASE solutions authenticates users through Kerberos, NTLM, Digest, and Basic authentication methods.  Meanwhile, captive portals authenticate users through Kerberos or OIDC. The reverse proxy part of SASE solutions typically uses either Kerberos or OIDC to authenticate users. VPN Gateway of SASE also authenticates users with Enterprise authentication databases. SASE solutions expect user information such as the identity provider that validated the user credentials, the user’s email address, the groups, and roles the user belongs to, etc. in JWT (JSON Web Token) format. SASE solutions use this information (known as claims in JWT terminology) to enforce identity-specific access controls.

Identity Broker

An identity broker is a service that acts as an intermediary, facilitating the authentication of end-users by SASE solutions with various Identity Providers (IdPs). Not all IdPs implement all authentication protocols; some may only implement OIDC, OAuth2, or SAMLv2. Since SASE solutions are designed to work with multiple IdPs, their complexity increases as they need to support different authentication protocols. Identity brokers, as trusted intermediary services, can enable the SASE solution to use a single authentication protocol in the backend and let the Identity Broker proxy the authentication process to IdPs via the authentication protocols that IdPs support.

Following picture depicts SASE solution with and without identity broker.

The left side of the picture shows SASE without an identity broker:

User browsers/apps authenticate to the SASE forward proxy using Kerberos, NTLM, username/password, Username/Digest-password.  SASE needs to validate user credentials. It uses multiple backend functional modules to talk to various IdPs/Authentication systems.  In case of Kerberos, service ticket is validated locally within the SASE data plane and then it gets user decorations from Authentication systems such as AD via LDAP or SCIM.  In case of username/password, LDAP backend is used for validating user credentials also.

SASE reverse proxy and captive portals authenticate users either via OIDC (Open ID Connect) or via SAMLv2.  If the backend IdPs is also OIDC or SAMLv2 based, then it redirects the users to IdPs. In case of LDAP based systems,  SASE is expected to work as IdP and use LDAP to AD for validating user credentials and also to get user decorations to create the identity token in JWT form.

VPN Gateway is another module that is used for remote access.  As part of the IKEv2 tunnel establishment, VPN gateway authenticates the user.  User credentials are validated with local DB, RADIUS server or LDAP server.

As you can see, multiple data plane components are required to support different protocols to work with various user browsers and native applications. Also, they need to work multiple IdPs of not only various tenants, but also multiple IdPs requirements within a tenant environment.

Right side of the picture shows SASE with inbuilt identity broker:

With identity broker, SASE data plane gets simplified dramatically.  SASE data plane only needs to work with one authentication protocol towards the broker. In the above picture, OIDC is only protocol the SASE data plane needs to support.  Broker can orchestrate/federate authentication sessions with multiple IdPs.  The identity broker is also expected to create JWT from the user information from SAMLv2 security token, from JWT coming from the upstream IdP servers or from the user information in the local database or accessible via LDAP.  That is, identity broker designed for SASE is expected to provide JWT in all cases – Whether the user is authenticating using Kerberos via proxy headers, Kerberos via WWW headers, OIDC, IKEv2 and whether the IdPs are based on OIDC, SAMLv2 or LDAP.

There are multiple advantages of breaking down SASE data plane from SASE identity broker.  Some advantages are listed below.

1. Modularity makes the entire solution less complex, less error prone and hence more robust.
2. Secure:Identity broker can be instantiated separately from the SASE data plane in confidential computing environments to ensure that the keys/passwords/credentials used to communicate with IdPs are protected even while they are in use.
3. Extensibility:New IdPs with newer authentication protocols can be supported without impacting the SASE data plane.
4. Consolidation:Identity broker solutions are increasingly being considered for other applications as well. Enterprises can use identity broker coming with SASE solution for their applications instead of going with separate identity broker service/solution.

SASE specific features

Identity broker functionality can indeed play a significant role in stopping direct access to SaaS/Cloud services by enforcing policy checks and ensuring that only authenticated users with appropriate access control can access these resources. In addition, traditional identity brokers may not have good support for proxy Kerberos, which is essential for SASE authentication. Therefore, it is important for identity brokers to have support for proxy Kerberos and other SASE requirements to effectively integrate with SASE solutions. By providing these enhancements, identity brokers can improve the security and ease of use of SASE solutions for enterprises.

1. Ensuring identity-based access control for SaaS and cloud services always and deterministically: Enterprises are increasingly using SaaS and cloud infrastructure services, which can be accessed from anywhere. This is a great advantage, but also a security concern for many enterprises. Enterprises want to restrict access to their data in SaaS/Cloud services for specific employees, and SASE is expected to ensure that. However, this is only possible if user traffic to SaaS/Cloud services is going via SASE data plane. If traffic is going to SaaS/Cloud services directly, bypassing the SASE data plane, it is expected that access will be denied. An identity broker can help in stopping these accesses. By configuring the SaaS/Cloud services to use the SASE identity broker, any new user authentication session lands first on the SASE identity broker. The SASE identity broker, via its policy checks, can stop users from accessing services directly.
2. Support for Kerberos grant: For many use cases, implicit authorization grant type and password grant types are sufficient. However, these two grant types are not sufficient to support Kerberos authentication. The expectation is that the SASE data plane, once it receives the Kerberos service ticket, either via proxy headers or WWW-headers from the user (browsers, for example), is expected to validate the service ticket and get corresponding user decorations from authentication databases. Since the broker is used for validating the credentials, the OIDC protocol implementation requires enhancement to support sending the service ticket from the SASE data plane to the identity broker and get the JWT if the credentials are validated.

Final thoughts

Identity brokers can indeed play a crucial role in a comprehensive SASE (Secure Access Service Edge) solution. By integrating an identity broker into the SASE architecture, organizations can simplify the integration of identity and access management (IAM) solutions with their SASE infrastructure. This can lead to a more streamlined and secure authentication and access control process for users.

Additionally, by enforcing zero-trust security principles, an identity broker can help ensure that only authorized users are accessing resources within the SASE environment. This can help reduce the risk of data breaches and other security incidents.

While industry analysts may not currently be discussing identity brokers in the context of SASE, it’s possible that this may change as organizations continue to look for ways to enhance the security and efficiency of their IT environments.

• 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.