Excalibur MFA/PAM - Deployment documentation¶

Introduction¶

Excalibur utilizes the mobile phone to act as a secure hardware token for any and all authentication and authorization needs inside of the enterprise. The ultimate goal is to move all forms of authentication and authorization away from passwords, replacing them seamlessly with smartphone-based strong but user friendly multi-factor authentication. Excalibur’s unique value is in providing backward compatibility with all the applications, Operating System (OS) and services the enterprise uses today creating a bridge between the password-based present day and password-free future.

Excalibur is not limited to OS login. Excalibur Privileged Access Management (PAM) and SAM provide web-based access to Enterprise resources – acting as a HTML5 to other protocols proxy server (Remote Desktop Protocol (RDP), SSH, Telnet, Virtual Network Computing (VNC) or even Browser access).

One of the core innovations of Excalibur is its ability to defeat all attacks on credentials as Excalibur is able to automatically change password on each login. In the Excalibur user flow – the password is no longer entered by the user – the user never even knows the password, it is just a random string used in the background, seamlessly injected into the login process by Excalibur. The user instead just interacts with the mobile phone – using it to provide various authentication factors as required by the defined security policy.

In Excalibur PAM - zero-trust means the client machine doesn’t need to be trusted as nothing is installed on it and all access from it goes via browser. The client machine doesn’t get access to the internal network so viruses, malware, ransomware etc. cannot spread.

As Excalibur is passwordless the user authentication is zero-trust too, the user has no way to delegate the access granted to him as access is tied to his smartphone (ownership factor), location factor (such as his branch office), knowledge factor (his Personal Identification Number (PIN) code) and ideally some form of biometry (HW on device biometric sensor and/or front facing camera facial recognition).

Excalibur PAM considers all sessions “privileged” and by default recorded. That’s why we also tend to call it SAM - Streamed Access Management. Every action taken by the user is cryptographically signed to certify it was performed by the authenticated user. The effect of this is that there is continuous matching of every user action (as every user action and user PAM session is recorded and cryptographically signed) to strongly multi-factor authenticated identity. With no way to delegate access or claim it was some other user. Excalibur is by itself zero-trust, all credentials are cryptographically distributed across the server and the user phone so that they can not leak from the Excalibur server – protecting data at rest. Every action performed by Excalibur is verified on all elements participating in its execution meaning that even if the Excalibur server would be compromised the attacker would not be able to leak any useful information nor impersonate any other user.

Even despite all precautions – Excalibur PAM can function without the need to store any credentials in it – in that case it just creates a proxy and the authentication itself will be performed in the PAM session. For example – imagine an RDP session with Network Level Authentication (NLA) disabled – Excalibur PAM creates just an RDP to HTML5 proxy – the Windows login screen will be displayed. Excalibur has industry unique Windows integration – making it completely password-less to login to any Windows machine / resource – if our windows component is installed on the destination server the user will just see a QR code to login exactly as everywhere else in Excalibur. This way the Excalibur PAM can be completely password-free / have no stored credentials – effectively creating a zero-trust PAM.

Rather than separating PAM/SAM and authentication, in Excalibur PAM/SAM and authentication is understood as strongly coupled, related, security measures, which best work together. Excalibur is conceptually designed to operate using the whitelisting principle. This means that everything that is not explicitly allowed is denied. Hiding assets behind Excalibur allows combining PAM/SAM and authentication into one element. Assets do not need to be exposed anymore, so attacking them directly is no longer possible.

Excalibur's preferred deployment model is hybrid-cloud in which server and database are located in a cloud that is run by Excalibur or a partner of Excalibur, other components such as Active Directory (AD) Facade, OS clients etc are located in the customer network. To allow for PAM/SAM to work in a hybrid cloud environment - automated tunneling utilizing the SSH protocol is used (TRESK).

There are several use cases for Excalibur:

Windows Multi Factor Authentication (MFA) login;
Integration with existing infrastructure / 3^rd party applications via standard protocols and technologies (such as AD, Fast IDentity Online (FIDO), Lightweight Directory Access Protocol (LDAP), Single Sign On (SSO), Security Assertion Markup Language (SAML) etc.);
PAM/SAM for remote access to standard protocols (such as HTTP/HTTPS, RDP, SSH, VNC, Telnet, Kubernetes etc.

The aim of this document is to help understand the available deployment options and associated considerations.

Deployment types¶

Excalibur has two deployment models. Traditional on-premise deployment, or our currently prefered hybrid-cloud deployment model. Hybrid-cloud deployment model enables us to update and troubleshoot our services faster and more easily. Choosing a deployment model is an essential first step in deploying the Excalibur system. To better understation and dedication of main Excalibur components please refer to section Main Excalibur Components within this document.

On-premise deployment¶

In the on-premise deployment model every Excalibur component (except Excalibur CA) is installed in the customer network, what creates a lot of responsibilities for the customer and their IT department. Customer is responsible for maintaining all the components and also for creating support channels for Excalibur teams. Multiple environments (e.g. DEV/INT/PROD) in the customer network are recommended what can significantly delay software updates. This deployment model is recommended for customers with a strong IT department and strong desire to manage all the components and data by themself.

Deployment considerations

Components are located in the customer's network.
Only Excalibur CA is situated in the cloud.
Customer is responsible for maintaining / operation of all components in their network.
Support is complex, remote access is necessary.
Software updates are delayed as they have to go through several DEV/INT/PROD environments.

Hybrid-cloud deployment¶

Hybrid-cloud deployment model is our recommended approach. Excalibur Server together with the database are located in our cloud environment and just the AD Facade, Clients and TRESK server are installed in the customer network. This enables us to better troubleshoot problems and deliver updates faster. Data is stored in our optimized cloud database, which speeds up Excalibur actions, yet data backups can be stored in the customer database if need be.

Deployment considerations

Excalibur/Partner managed service.
Minimalized deployment complexity for the customer.
Software updates are immediate.
Support is immediate, remote access into customer infrastructure is not necessary.
The TRESK component is necessary for PAM/SAM access to resources inside of the customer network and for Facade/Clients connections to access server.

Main Excalibur Components¶

In this section the main Excalibur components, their functions, options and frequently asked questions are discussed. The Excalibur system architecture is modular, components can be added and even removed from some specific deployments. However, components listed in this section are typically part of every deployment. Component considerations can be different based on the deployment type.

Excalibur Server¶

Excalibur Server provides a persistent network and storage central point, and therefore must be accessible from all components. It also provides a web-based management interface - the Dashboard, as well as API (WebSDK, SAML, …), which takes care of communication and operations with integration components. Excalibur PAM is part of Excalibur Dashboard running on the Excalibur server. More details in Excalibur Administrator Dashboard Manual

Deployment considerations

hybrid-cloud
- no extra infrastructure needed for Excalibur Server on customer's side
on-premise - single (non HA architecture)
- Minimal requirements
  - 8 CPU cores
  - 8 GB of RAM
  - 100 GB of disk for OS / application / internal DB use.
- The preferred Excalibur Server Operating System is the latest Ubuntu Server LTS at the time of deployment. Other Linux distributions can also be used with prior notice before deployment for compatibility testing.
- Excalibur Server is shipped as Docker Swarm stack so the latest Docker Engine should be installed on the host machine.
- PAM
  - at least 200GB of disk capacity (capacity sufficient for pilot including the PAM session recordings)
on-premise - multi-node (HA architecture)
- see section High availability section within this document.

Excalibur Token¶

The Excalibur mobile application utilizes the user’s mobile phone as a hardware security token - therefore in Excalibur, we call the mobile phone the token. It is primarily used to interact with the user - input of authentication factors, viewing of sessions and their history as well as providing capability to remote lock / logout sessions. Excalibur Token uses the biometric sensors if available and the hardware secure element if supported by the phone. More details in Excalibur User Manual.

Deployment considerations

Mobile app can be distributed via platform specific app stores (PlayStore, AppleStore) or via corporate MDM.
Android 6 and newer are preferred due to native fingerprint support.
iOS 10 and newer.
Hardware biometric sensor is recommended on all devices.

Excalibur Client¶

In the context of Excalibur, the client is usually a PC with our software package called the Excalibur Client installed. The client component provides the Excalibur login screen that is displayed on top of the default Operating System login screen / lock screen. This is achieved utilizing the Excalibur Credential Provider (CP). More details in Excalibur Client documentation.

Deployment considerations

any Windows 7 / Windows 2008R2 and newer
both 32 and 64 bit OS versions are supported.
For zero-trust Excalibur PAM – Excalibur client must be installed on the Windows server where RemoteApps / Remote Desktop will be running – this way Excalibur PAM does not need to ever handle any credentials.

Excalibur Facade¶

Component that interacts with the Active Directory (AD) and thus must be installed on at least one domain-joined server, preferably on a Domain Controller (AD DS role). It runs as a system service and interacts with the AD utilizing the Remote Protocol Directory Replication Service (DRS) or LDAP as a backup option. Facade also performs cryptographic operations for most of Excalibur actions. More details in Excalibur AD Facade Manual.

Deployment considerations

OS: Microsoft Windows Server 2008 R2 or newer
64bit only
gMSA or ADDC
Facade must be installed on an Active Directory Server in the domain where the pilot users are and pilot machines are domain-joined
Facade does perform cryptographic operations for which the server should have sufficient CPU capacity to accommodate.

Database¶

Built-in single/multi-node high availability MariaDB database. If requested any of the following database engines can be used as external storage for backup snapshots:

Oracle SQL
MySQL / MariaDB

Deployment considerations

on-premise - appropriate HW resources are needed
hybrid-cloud - completely created and maintained by Excalibur or a partner of Excalibur

Excalibur CA¶

Excalibur Certificate Authority (CA) issues certificates to other Excalibur components. For security reasons, Excalibur provides a cloud-based CA - so that even if the customer is fully compromised the attacker will not gain control over provisioning of new user tokens or impersonating existing tokens. More details in Excalibur Whitepaper documentation.

Deployment considerations

Excalibur CA is fully maintained by Excalibur in a cloud environment so the only requirement is direct network connection for Excalibur Tokens.

High availability¶

The architecture of Excalibur Server is fully based on Docker which includes swarm mode for natively managing a cluster of Docker Engines called a swarm¹. As a part of this cluster there are two execution nodes which operate in active - passive mode and thus only one node at the time is responsible for all core operations. All incoming connections must be also routed to this node

Docker Swarm¶

A Docker Swarm consists of multiple Docker hosts (nodes) which run in swarm mode and act as managers and workers. There is no need for additional orchestration software to create or manage a swarm. If any node becomes unavailable, Docker schedules that node’s tasks on other nodes. The swarm manager uses ingress load balancing to expose the services that need to be available externally to the swarm. Each node in the swarm enforces TLS mutual authentication and encryption to secure communications between itself and all other nodes. One of the key advantages of swarm services is that a service’s configuration can be modified, including the networks and volumes it is connected to, without the need to manually restart the service. Docker will update the configuration, stop the service tasks with the out of date configuration, and create new ones matching the desired configuration. This technology is used for Excalibur to ensure high availability of services.

The basic configuration of the Excalibur Docker swarm to ensure high availability of Excalibur consists of a cluster of at least 3 nodes. Where a pair of nodes (node #1,#2) take over the role of execution and control nodes, the other node (node #3) is used only for the management of the swarm services. The minimum number of manager nodes is due to the fact that internally Docker swarm creates a quorum of manager nodes (managers) based on the Raft consensus algorithm², where to ensure high availability it is necessary to allocate an odd number of managers and at a given moment must be a majority of manager nodes active. The minimum hardware requirements for such nodes are therefore different:

node #1, #2 - because these nodes act as manager and worker at the same time, the hardware requirements are defined in the deployment considerations of Excalibur Server section within this document.
node #3 - the role of these nodes is to maintain a consistent quorum of managers and by performing only tasks related to the management of tasks/services their hardware requirements are as follows:

2 CPU cores
2 GB of RAM
10 GB of disk space for OS / Docker runtime

Such a swarm configuration can be identically applied to multiple physical (virtual) machines within a single data center as well as across multiple data centers. The communication connection of nodes is secured by an overlay network.

Service migration¶

Due to the current architecture of the Excalibur system, it is not possible/efficient to distribute the load of internal processes through several nodes, therefore the execution nodes operate in active - passive mode and in case of failure of the active node, the running services are automatically migrated to the passive node, which becomes active at that moment. Service availability of the primary node is checked by an internal healthcheck mechanism and the new placement of services/containers is automatically enforced by the internal orchestration mechanism of the swarm and defined by constraints and placement preferences³ . Existing connections to the inactive node need to be explicitly terminated to force the re-connection of external components (Excalibur Client, Excalibur Token, Excalibur Facade) to the new active node.

Database¶

To ensure high availability of the database, a local instance of the database is present on each execution node (#1,#2) within the cluster and the data is replicated (master-master) on the secondary site. In case of larger deployments or increased requirements for high availability, it is possible to create a Galera Cluster⁴. This solution requires a higher number of execution nodes that will be part of the database cluster. Additional database backup can be provided by using active connection to an external database repository where snapshots of the active database are stored at regular intervals. Alternatively, it is possible to export database dumps to a secured external storage. To minimize data loss, it is also possible to store binary database logs that contain information about data modifications in the time interval between two snapshots.

Automatic failover¶

All services are running only on the current primary / active node. All traffic is routed to this node. Service availability is checked by the primary / active node using an internal health-check mechanism. Also, a quorum of managers monitors the availability of the active node itself. In case of service/container unavailability failure after the timeout interval, the service is automatically rescheduled to the next (passive) node by the primary management node. At this point, a short service drop occurs which is caused by the timeout and the time needed to start the container on the other node. The redirection of the traffic to the active node is ensured by monitoring the availability of the service on the current active node using the pingServlet (Excalibur Application Monitoring).
The master-master replication also ensures that in case of unavailability of the primary node, all data changes made to the secondary node database are replicated back to the primary node, or in the case of a galera cluster, to all remaining nodes.

Deployment considerations

Minimum of 3 nodes participating in Excalibur Docker Swarm.
Failover manager (node #3) must have HA properties and in case of failure, must be re-spawned to accomplish managers quorum.
All nodes must be reachable to each other with enough network bandwidth between them.
Traffic must be forwarded to only active node.
Service load can be partially balanced.
Architecture supports multiple options to HA database.

Network communication¶

This chapter describes network connections from Excalibur Components or third-party services (Push Messages) to/from the Excalibur Server as well as connections between multiple Excalibur servers. Excalibur Server is built on top of the Docker Swarm technology which can be used for achieving High Availability (HA), the corresponding connections need to be allowed by the customer IT department.

Server connections¶

Most of the Excalibur components connect to the Excalibur Server, corresponding protocols, ports and other details are listed in this chapter. Excalibur Server connects to the PAM targets using multiple protocols, and these targets need to be accessible from the server or to the TRESK-VM in case TRESK is being used. Excalibur Server is also connecting to the third-party (Google, Apple) service for the push messages.

Application server port - connections on this port handle core communication by main components thus must be reachable by all clients and tokens (ideally reachable from the public Internet). Connection properties are:

port - 6632
type - TCP
protocol - HTTP upgraded to Websocket
security - mutually authenticated TLS

Facade port - connections on this port are used only by Facade components to exchange messages with Excalibur Server. This port must be reachable only from the Active Directory Server or domain joined server on which the Facade component is installed (strictly reachable from internal network). Tresk-VM can be used to tunnel this port. Connections properties are:

port - 65321
type - TCP
protocol - HTTP upgraded to Websocket
security - mutually authenticated TLS

Dashboard/API port - resources accessible on this port are used by end users (employee - PAM, administrator - Dashboard administration) or external systems (API, SAML SP, …) thus must be reachable from networks where accessing entities are situated. Connections properties are:

port - 443
type - TCP
protocol - HTTPS
security - TLS

TRESK-Server port - connections on this port are only used by TRESK-VM or TRESK-Client to establish a secure forwarding tunnel thus must be reachable from networks where those components are situated. Connections properties are:

port - 43022
type - TCP
protocol - SSH
security - Mutual Public Key Authentication

Excalibur connects to push notification servers to send push notifications to registered Tokens. Firewall must be configured to allow this Excalibur Server outgoing communication.

Firebase cloud messaging (Android) - all IP ranges from AS15169, destination ports 5228, 5229, 5230 (TCP)⁵
Apple Push (iPhone) - 17.0.0.0/8, destination ports 443, 2195, 2196, 2197, 5223 (TCP)⁶

Database - in case that external database is used instead of the build-in instance or external database is used as a backup storage, then appropriate ports must be allowed on the firewall. Resp. TRESK tunneling can be set up for this purpose.

Swarm overlay network¶

Distributed network among multiple Docker daemon hosts (in case of multi-node deployment). This network sits on top of (overlays) the host-specific networks, allowing containers connected to it (including swarm service containers) to communicate securely when encryption is enabled. Docker transparently handles routing of each packet to and from the correct Docker daemon host and the correct destination container.

The following ports need to be open on each Docker host participating in an overlay network:

TCP port 2377 for cluster management communications
TCP and UDP port 7946 for communication among nodes
UDP port 4789 for overlay network traffic

When overlay encryption is enabled, Docker creates IPSEC tunnels between all the nodes where tasks are scheduled for services attached to the overlay network. These tunnels use the AES algorithm in GCM mode and manager nodes automatically rotate the keys every 12 hours.

Features¶

Excalibur provides various integrations with existing infrastructure. Features are selected and installed based on the individual customer needs. Some of the features are included in the Excalibur system and some require additional component installation, such as the TRESK or PAM. This chapter describes main Excalibur features together with the basic info about required components and deployment considerations for each individual feature. Excalibur features are described only at a high level in this document, for more details go to the Excalibur documentation website.

Most basic feature of Excalibur is login into the Operating System. Login (authentication) is performed by scanning the dynamically changing (by default every 15 seconds, with 90 seconds validity) QR code from the display of the device where Excalibur Client was installed. The login QR code contains all necessary parameters to perform action and by its dynamic nature provides a proximity feature - the user must be physically at the device to be able to scan it as it has limited time validity. During authentication all security factors defined by security policy are verified and after successful verification password is securely reconstructed (Excalibur Whitepaper) and injected into the login process.

With Excalibur Client user can perform three types of authentications (Excalibur User Manual):

online login - Excalibur Token and Excalibur Client participating in authentication must have active (and stable) connectivity to the server.
offline login - one or both interacting components have problems with connectivity and Excalibur will allow to log in using offline One-Time Password (OTP).
token-less login - fallback option/feature of Excalibur Client in cases when phone is missing or non functional

Deployment considerations

Currently only Windows implementation of Excalibur Client is available.
Offline login is possible only after the first successful online login.
OTP has a limited validity and is valid only for one offline login to the computer.
The ability to login without a mobile phone with Excalibur may be prohibited by the administrator using security policies.

TRESK¶

In the Excalibur context TRESK (Tunnel Resolver Component) allows access to any Target inside the Intranet with almost zero infrastructure or policy (re)configuration. More details in Excalibur Tresk Whitepaper documentation.

TRESK consists of several components:

cloud infrastructure
- TRESK-Server
customer`s infrastructure
- TRESK-VM
- TRESK-Client

TRESK-Server¶

TRESK-Server provides an endpoint which serves TRESK-VM or TRESK-Client SSH tunnel initialization and handles actions needed for successful SSH tunnel establishment, such as creating temporary users with appropriate public/private key pair authentication etc.

TRESK-VM¶

The purpose of TRESK-VM is to provide access to the Targets from the TRESK-Server side, since the Targets are usually inaccessible from the Cloud environment. It is implemented as a Docker container, deployed in the customer's internal network (Intranet). TRESK-VM provides an encrypted connection between the target service or computer (target) in the Intranet and the TRESK-Server component on the Excalibur Cloud side, via the so-called SSH port forwarding (or SSH tunneling).

Deployment considerations

Operating system: Any OS capable of running Docker
TRESK-VM must be able to connect to the TRESK Server
Targets must be accessible by TRESK-VM host

TRESK-Client¶

TRESK-Client component is realized as a script (Bash on Linux or PowerShell on Windows) installed directly on Target, with no further dependencies needed from the OS. TRESK-Client initializes SSH tunnel to TRESK-Server. After successful SSH tunnel initialization Target’s services are available from TRESK-Server through TRESK-Client via specific ports.

Deployment considerations

Operating system: Windows 7 or later, Linux
TRESK-Client must be able to connect to the TRESK-Server (Excalibur Server)
Running TRESK-Client script does not require any special OS permissions nor any further OS dependencies
The use of TRESK-Client is dedicated to cases when connection to TRESK-Server is not possible thru TRESK-VM.

SAML¶

Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions (statements that service providers use to make access-control decisions).

Excalibur Server acts as identity provider (IDP), so authentication can be unified across all service providers (SP) providing a secure and seamless Excalibur authentication experience. Service Providers are services like Office365, Cisco ASA, Gmail etc to which Excalibur provides users. Those providers are configured metadata stored on Excalibur Server. Administrators can add/edit/remove SPs properties through the SAML dashboard section (Excalibur Administrator Dashboard Manual).

Flow which user experience during authentication by using Excalibur SAML as authentication authority is almost identical to the process of login into the operating system by using Excalibur Client logon screen (Excalibur User Manual). During authentication process two system calls to Excalibur Server API are made:

SAML post - SAML authentication request from SP is sent from the user's browser to the IDP by using html form.
SAML redirect - redirection is returned upon authentication call to SP. Authentication request is part of URL parameters

More advanced description of Excalibur SAML IDP is in the documentation (Excalibur SAML Integration).

Deployment considerations

SAML is a standard, so any SAML Service Provider should be supported, but some SP implementations have specific requirements, so integrations need to be tested against each SP implementation.
Users are typically managed by Excalibur and are created on demand in the given SP, but some SP implementations require users to be manually created before actual authentication.
SAML is using certificates, which are stored on the server, therefore use of HSM is recommended.
SAML messages are transferred through the user browser, so the IDP does not have to be able to reach SP and vice versa. Only the user’s browser needs to be able to access both IDP and SP.

PAM¶

Excalibur PAM (Privileged Access Management) is able to provide controlled access to most services / servers / applications by supporting a wide range of protocols. All these applications can be accessed by any web browser supporting HTML5, even mobile web browsers are supported.

Access to PAM protected resources is granted only on a whitelitesd basis. Clients can not access the protected resource directly, only via Excalibur PAM after being strongly multi-factor authenticated into Excalibur Dashboard. More details in Excalibur PAM Manual.

Protocols currently supported by Excalibur heavily customized Apache Guacamole⁷:

Standard
- SSH
- VNC
- RDP
Web resources:
- Virtual Browser
- HTTP-Proxy

Deployment considerations

Virtual Browser and HTTP-Proxy are both capable of authenticating user via the SAML protocol.
Access to Excalibur can be further restricted by requiring a VPN that would configure the default gateway in a way that would route all traffic thru the VPN to the effect that only Excalibur would be accessible from the PC when the VPN would be connected - thus the PC would not have Internet connectivity when connected to the VPN - effectively defeating a wide range of potential attacks where the PC could be compromised and remotely controlled by an malicious third party.
All access to PAM resources is recorded.
SAML authentication is integrated directly into the HTTP-Proxy / Virtual Browser.

Virtual Browser¶

Virtual Browser (VB) is Excalibur’s implementation of Remote Browser Isolation (RBI). It works by streaming vector images from a server-based instance of Chromium while allowing full remote control of this browser instance by the user directly from his web browser. This is beneficial mainly for security reasons, since the client's browser does not have access to the original HTML page, nor Javascript or cookies etc. DOM is executed in the Virtual Browser, so a web page is completely isolated from the client's browser, thus the name -- Virtual Browser. In contrast to video codecs - Virtual browser works with vector graphics and only the modified parts of the image are transfered. This means that the image / text quality presented to the end user is always lossless, no matter the resolution, frame-rate or other factors. As with all Excalibur PAM components - Virtual Browser records all sessions (server-side recording). User input is indexed and saved, so it can be used for pattern matching, or other analytics purposes.

Deployment considerations

Attackers can not attack the protected web resource as all access to it is just “streamed” to the user, also the user is protected from any malicious activity from the web resource as DOM is isolated on the server.
Server-side recording.
USB token authentication solutions can’t be used, because DOM is completely isolated - aka not running on the computer where the USB token is plugged in.

HTTP-Proxy¶

HTTP-Proxy is a light-weight alternative to Virtual Browser. It serves a similar purpose as Virtual Browser, but does not share the same security advantages such as complete DOM isolation, yet it has its own benefits - mostly compatibility wise. It terminates HTTP(S) connection from the client and creates a new one to the server, effectively acting as a Man-in-the-Middle. Main difference between HTTP-Proxy and Virtual Browser is where HTML DOM is executed / interpreted. Virtual Browser executes all code on the server side, which has its security benefits and compatibility limitations. On the other hand HTTP-Proxy just proxies traffic, so the code is executed in the client’s browser.

Deployment considerations

Client-side recording.
DOM is executed directly on the client.
HTTP / HTTPS is proxied via Excalibur.
Excalibur smartphone based multi-factor authentication (MFA) can be combined with other authentication mechanisms such as USB authentication tokens.
Benefit of HTTP-Proxy approach over Virtual Browser is that existing PKI-based authentication mechanisms continue to function while providing the same “business value” - recording of all user activity, no direct connectivity, connectivity only after being strongly multi-factor authenticated.