• Overview
  • Authentication Point - TrustProvider
  • Access Point - Access Tier
  • Continuous Authorization

This article makes several simplifying assumptions in order to describe complicated security concepts in a concise manner.

Overview

Cloud Secure Edge’s zero-trust access policies are authorization policies evaluated and applied one-time at the Authentication point (i.e., the TrustProvider Component) and then continuously at the Access point (i.e., the Access Tier Component).

Authentication Point - TrustProvider

At the Authentication Point (TrustProvider), the user and device are validated, and an OpenID Connect JWT token (aka TrustToken) is issued.

As in the diagram above, policy evaluation at TrustProvider is completed in four steps:

1. Unregistered Devices - Connections from devices that are not registered with CSE and thus do not present a Device Certificate are immediately dropped, unless explicitly exemptions are made in the TrustProvider Settings section of the Web Console.

2. Device Phase - In the Device Phase, the Device Certificate is checked for validity and revocation. Then, the Device attributes are extracted for use in policy decisions.

3. User Phase - In the User Phase, TrustProvider federates with the Enterprise Identity Provider to authenticate the user. Then, User attributes are extracted from the IDP for use in policy decisions.

4. Policy Check - Once the Device and User have been authenticated, we compute the Roles and Trust Level for this User-Device combination. Policy is checked to ensure that this User-Device has permission to access the Service they are requesting.

Once all steps are completed successfully, TrustProvider issues an OpenID Connect JWT token (aka TrustToken). Here is an example of a TrustToken payload, with User and Device attributes:

{
  "at_hash": "7GTdxu5jhGVf-tvLSg_c2A",
  "aud": "orgname.RPuYHSPIJmjWT21V_Ov65w",
  "device_id": "a1d0c77f-a5a4-4843-a9a0-6e538fb1d1ab",
  "email": "test123@banyanops.com",
  "email_verified": true,
  "exp": 1572238934,
  "groups": [
    "contractors"
  ],
  "iat": 1572152534,
  "iss": "https://<ORGNAME>.trust.banyanops.com/v2",
  "name": "Test 123",
  "nonce": "Xy0wRHlQ1RXXYdFukcVOV",
  "serial_number": "L1HF8BL1234",
  "sub": "CiQyOTgzN2JjNi0wMTAwLTQ5ZDgtYmQwZS03OTZiYWQ5MWU4NjYSE25vdnBudGVzdC1jb25uZWN0b3I"
}

Following the OIDC protocol, the TrustToken can only be used to access the specific Service it was issued for (as specified in its aud field), and is valid only for a short lifetime (as indicated in its exp field). The TrustToken token lifetime is set to 24 hours by default, but can be customized to any value between 2 hours and 72 hours.

For access to HTTP Registered Services, the TrustToken is embedded in a HTTP cookie (aka bnn_trust or TrustCookie). The TrustCookie is a Secure, HTTPOnly, Session cookie scoped to the Domain of the specific Service the TrustToken was issued for. Because it is a Session cookie, the TrustCookie will be deleted once the browser is closed; the user has to re-authenticate whenever they open up a new browser session.

For access to TCP Registered Services, the desktop app exchanges the TrustToken for a short-lived X.509 client certificate (aka TrustCert). The TrustCert’s expiration date is set to the same value as the token lifetime of its TrustToken.

Note: To configure the token lifetime of the TrustToken and Trust Cert, navigate to Settings > TrustProvider Settings > Advanced Settings in the Command Center. Read more in our article on managing cryptographic tokens and certificates.

Access Point - Access Tier

At the Access Point, the CSE Enforcement Component, i.e., the Access Tier, checks connections and requests for the TrustToken (either in the format of a TrustCookie or a TrustCert) to continuously authorize access into a secured Service.

As in the diagram above, connection/request handling and policy evaluation at the Access Tier is completed in four steps:

1. Routing Logic - Routing to the correct Backend destination is typically done using TLS Server Name Indication (SNI) - connections from clients that do not provide the correct SNI in the TLS handshake are dropped.

2. Connection Level - If the Policy specification says that Mutual Auth TLS should be used, a client certificate is requested during the TLS handshake. Once the client certificate (that is, the TrustCert) is verified, entity attributes are extracted from the TrustCert for use in the Policy decision.

3. Request Level - If the Service specification says that OpenID Connect JWT should be used, the request is redirected to TrustProvider to obtain a TrustToken that can be embedded into a cookie (that is, the TrustCookie). Once the cookie is verified, entity attributes are extracted from the TrustCookie for use in the Policy decision.

4. Policy Check - Once the Client has been authenticated, we compute the Roles and Trust Level. Policy is checked to ensure that this Client has permission to access the Service they are requesting.

Once all steps are completed successfully, Access Tier authorizes access to the Service it is securing.

Continuous Authorization

CSE’s security policies are enforced continuously at the Access Point. If any change is made to the Roles or Trust Level for any Client, an out-of-band message is sent from the Cloud Command Center to the Access Tiers.

Policy is re-evaluated without disrupting any existing connections. If needed, previously authorized accesses are blocked in real-time.