Mixed-mode Services (Deprecated)
Configure a Web Service to support multiple types of clients - Browsers, CLIs, Workloads, etc
- Updated on Oct 17, 2024
Cloud Secure Edge’s (CSE) Mixed-mode support went into early preview around Feb-2020 but has been deprecated as of Release 2.40 in Oct-2020. Customer feedback and our own experience indicates it is easier and cleaner to define 2 Services - 1 WEB, 1 TCP - to accomplish what Mixed-mode was trying to.
Motivation
CSE supports two standards-compliant mechanisms for zero-trust authentication and authorization:
- OpenID Connect (OIDC) authentication for Web Services
- Mutually Authenticated TLS (MTLS) for TCP Services
Typically, a given service is secured by one of these mechanisms. For some types of web applications that are accessed by a diverse pool of clients (such as Browsers, CLI tools, Automation scripts, and/or Workloads), you may want to provision access via both mechanisms. We call this capability Mixed-mode, which essentially allows Web services that are secured using an OIDC flow to also accept short-lived X.509 client certificates for authentication.
How It Works
When a Mixed-mode policy is attached to a Web Service, Netagent performs a MTLS handshake and decides how to manage access depending on the presence and type of the client certificate provided.
CSE issues and recognizes 3 types of X.509 client certificates:
| Cert Nickname | Subject CN Format | Primary Purpose | Validity Period |
|---|---|---|---|
| DeviceCert | ManagedDevice-BNN ... |
Device registration | 1 year |
| TrustCert | Banyan Client ... |
Access to TCP Services via Desktop App | 24 hours (adjustable) |
| WorkloadCert | Banyan Netagent ... |
Service-to-service authNZ | 1 year (auto-rotated every 24 hours) |
As depicted in the diagram below, Netagent uses the client certificate presented in the MTLS handshake to decide whether or not to use OIDC authentication, and how to grant access.
Limitations
There a few feature limitations to be aware of in our current implementation of Mixed-mode.
Backend TLS
Mixed-mode requires non-Browser clients to make HTTP (and not HTTPS) requests
For non-Browser clients to access a Mixed-mode service, their connection needs to the upgraded to Mutual-Auth TLS via a client-side proxy - either the banyanproxy module of the Desktop App on a Device or the client-side Netagent on a Host. On the service end, the server-side Netagent will terminate this Mutual-Auth TLS connection, enforce policy, and forward the traffic to the Backend. Because an end-to-end TLS session is already established between the Device/Host and the server-side Netagent, a non-Browser client cannot use HTTPS to establish a second, end-to-end TLS connection directly between the non-Browser client and the backend service.
SNI Routing
Mixed-mode service definitions cannot support Workload clients if the SNI Routing is used.
In a Mixed-mode Service spec, if the tls_sni field is set, access from Workload clients will fail. This is because for Workload clients (a.k.a service-to-service connections) Netagent is deployed on the client side, and the client-side Netagent does not know the Service tls_sni setting. The client-side Netagent will not specify SNI correctly when making a request. However, the server side requires SNI for routing and will deny the request for invalid SNI.
Policy Enforcing / Permissive Mode
Mixed-mode services will force requests from unauthenticated clients into an OIDC Flow even if Policy is in Permissive Model
When a Policy is attached in Permissive mode to a TCP Service, the client certificate requirement is not strictly enforced - Netagent will still forward requests from an unauthenticated client to the backend and generate an “Unauthorized Access” event to alert the Admin. However, for Mixed-mode services, this behaviour is different. Regardless of whether the Policy is Enforcing or Permissive, if a client does not provide a client certificate, Netagent will force the request into an OIDC flow.
Configure a Mixed-mode Service
To configure a Mixed-mode Service:
1. Navigate from Private Access > Access Policies > + Create Policy, and create a new Policy using the template Basic Authorization Policy for Users.
2. Once the policy is created, click Edit Policy and then edit the policy spec. Change the disable_tls to false, and then add mixed_users_and_workloads and set it to true.
3. Navigate to Manage Services > Hosted Services and then click +Register Service. Then, create a new Service using the template Web Service for Users.
4. Attach the policy you configured in step 3 and then click Register Service.
That’s it! You have successfully configured a Mixed-mode Service in the Command Center. You can now access this Service from a variety of clients - Browsers, CLIs, Workloads, etc.