Token generation and flow
Before the first authentication, the Client will have a URL to one of the Controllers, and the Certificate Authority ("CA") certificate, either because these were automatically installed with the Client, or because the user entered the Controller URL manually and the Client downloaded the CA certificate. The Client will use the CA certificate in all communications to verify the authenticity of the Controller or Gateway.
When logging in to the system, the user enters credentials such as username and password, and the Controller verifies the credentials against a user directory. The Client will generate a random ID for itself if it does not already have one. This random ID will be sent along with the credentials.
On a successful authentication, the Controller replies with a Claims token. The Claims token is issued to a Distinguished Name ("DN") which includes both the user's ordinary DN and the client ID. This new DN will identify the session throughout the system.
The Client uses the Claims token to request Entitlement tokens.
The Controller queries its internal database to find all services that the user is entitled to, and replies to the Client with Entitlement tokens, one per Site.
The Client generates an RSA keypair for itself.
The Client sends a certificate signing request to the Controller, based on the Claims token and public key.
The Controller replies with a certificate for the Client. This is issued by the CA, to the same DN as in the Claims token, which includes both the user's ordinary DN and the Client ID.
Connecting to the right Gateway
The Client establishes a TLS (or DTLS) tunnel to one Gateway in each Site, using the Client certificate for Client-side TLS authentication.
The Client sends the Claims token, a number of (untrusted) device claims, and a Site-specific Entitlement token to each Gateway it is connected to.
Per-user firewalling
Each Gateway translates the Claims token, Client claims and Entitlement token into a list of firewall rules, which apply to that user on that Client computer at that specific time.
The Client can now send IP packets to endpoint servers through the TLS tunnel, provided that this is allowed by the firewall rules.
Step-up authentication using a condition - user interaction
A "user interaction" can be defined within a Condition to enforce additional security requirements (such as re-entering the user's password before allowing access to a protected resource).
The Client may send an IP packet which is not currently allowed by the firewall rules, but which may become allowed depending on run-time Conditions. The Gateway will detect this and see if a user interaction is associated with the currently forbidden destination.
The Gateway sends a user interaction to the Client over a websocket connection which the Client keeps open for the session. This user interaction can contain instructions for the user, or trigger specific actions in the Client, such as initiating a new user authentication. In this example, the user is prompted for two-factor authentication, which the Controller verifies using an authentication server.
The Controller replies with a new Claims token, which proves that the user has entered a valid authentication. The Client sends the new Claims token to the Gateway, which uses it to re-evaluate the Conditions in the Entitlement token, and produces new firewall rules.
With the new firewall rules in place, the Gateway will now allow packets to the destination which was previously blocked.
Depending on the type of user interaction, the user will be:
prompted to provide an OTP, which the Controller verifies using the OTP provider specified in the Condition. The Controller provides a new Claims-token with an updated OTP claim. The Client sends the new Claims token to the Gateway.
prompted to provide a reason for access: the text entered is sent to the Gateway as an untrusted Claim;
prompted to enter their password: the password is validated by the Controller using the identity provider specified in the user interaction, which can be the same one used for authentication or a different one identity provider;
shown a message explaining how to gain access (such as updating antivirus on the machine). If the user fixes the situation, the Client will eventually send a changed value for the client-side claim (such as antivirus status) to the Gateway.
shown a message for information purposes such as indicating why access cannot be granted at this time.
Updating Entitlements by revoking tokens
Immediate token updates
The administrator can force a user's Claims and Entitlement tokens to be renewed in real-time. By invoking an immediate token renewal, the token revocation list is updated and pushed out to all Gateways. The Gateway notifies the Client that tokens will expire shortly and will try to get new tokens to replace the expiring ones. The user will be unaware of this renewal process.
Refer to Disable, change or remove access for more information about performing token renewals.
