SKFS only exposes web services: Representational state transfer (REST) and Simple Object Access Protocol (SOAP). The server does not have to be built into web applications, and can run as an independent instance enabling all applications—regardless of the language/framework with which they're built—to use FIDO2 capabilities.

While the Tellaro appliance's cryptographic hardware module provides a tamper-evident key management device and enjoys all the benefits therefrom, the FIDO2 Server demo running in a Virtual Machine (VM) is not guaranteed to have the same level of security. When deployed on a VM, the secure element is simulated by software, which is by default not as secure as the hardware equivalent. For this reason StrongKey recommends not deploying the FIDO2 Server for a production environment in a VM, but instead only as a proof of concept for demonstration purposes.

When considering FIDO2 server deployment options, one can use a FIDO2 library and add it to the web application or deploy an independent server, as available on the StrongKey Tellaro. The independent server in the Tellaro has many advantages over libraries:

• It makes the web application “lighter” since it does not link any non-core libraries into the business application, and enables the application to merely make web service requests to use FIDO2 services
• It enables multiple web applications to use common, clustered FIDO2 Servers to strongly authenticate users across multiple applications, thus delivering the benefits of single sign-on without having to add additional single sign-on code
• It allows an application written in any programming language to use FIDO2 services as long as the application can call web services using the REST or SOAP protocols
• It enables web applications to take advantage of high availability (HA) and disaster recovery (DR) without having to design additional logic into the application to deliver this capability—when the StrongKey Tellaro is deployed in clusters, applications may communicate with any available node in the cluster to avail FIDO2 services
• It enables greater security since every Tellaro node has its own cryptographic hardware module to secure key management functions within the appliance (see the Security section of this chapter to learn more about this)

StrongKey Tellaro appliances are always installed in a clustered configuration for HA in a production environment. All the servers function in a master-master configuration where any server can receive transactions and will asynchronously replicate data records between all other nodes in the cluster without human intervention.

In the event a cluster node fails for any reason—network failure, power loss, hard disk crash—some “in-flight” transactions might fail, causing the registration or authentication transaction to be started over again.

While the failed node is not within the cluster, other nodes within the cluster hold all necessary transactions—such as newly registered keys—in a queue for the missing node. When the missing node rejoins the cluster, the remaining nodes in the cluster recognize its arrival and replay transactions from the replication queue to bring the missing node up to date.

When multiple Tellaro nodes are deployed across a wide area network (WAN) with a reasonable geographical distance between them, they also provide business continuity (BC) in the event of a disaster affecting a location where the services of one (set of) FIDO2 server(s) may be affected.

The diagrams in the next sections demonstrate different configurations to consider when deploying Tellaro appliances containing the FIDO2 Server.

Other Considerations

• The decision with regards to which load balancer is used by the application can be made based on where the request originates, so it reaches the closest data center for a faster response
• In either of these scenarios, it is recommended that a Transport Layer Security (TLS) digital certificate with a subjectAltName (Subject Alternative Name, or SAN) extension is created to include the fully qualified domain name (FQDN) for all Tellaros in the cluster, so that the calling applications only need to import one TLS certificate per cluster into their TrustStore
• StrongKey's implementation of the FIDO2 web services (register and authenticate) are two-step processes where a challenge (nonce) must be obtained in a preregister step before a registration, or in a preauthenticate step before an authentication can be completed. If the appliances are behind a load balancer, there is a possibility that the application can go to two different machines for the two steps:  preregister and register web services or the preauthenticate and authenticate web services. All challenges and sessions are stored in a map that is replicated to all other appliances in the cluster. The possibility of a small delay exists due to network problems between different data centers, or even between servers in the same data center. To compensate for such delays, developers can do one of the following:
  • Configure the load balancer to use sticky sessions so that the two related web services go to the same server for a guaranteed response
  • Design the application to handle this scenario and just retry the second register or authenticate web service again if it fails the first time
  • Build in a small delay between the two web services for replication to catch up

  In an ideal scenario, the replication is instantaneous and the application does not even notice if the web services go to a different data center.