The different architectures supported by the Trust1Connector
The Trust1Connector can be configured to comply with different installation scenario’s. This can be done when packaging the Trust1Connector, and is managed through setting the correct command-line arguments upon startup. To facilitate this, the Trust1Connector ships with a partner specific launcher which can be adapted to comply with different reqeusts.
The Trust1Connector can be installed in different ways, depending on the requirements for a specific business context. By default the Trust1Connector uses the best approach for a device in an unknown context.
The different setups describes below all share *the same codebase*. For each target the executables are exactly the same.
We achieve this through command line parametrization of the executable. Updating the CLI parameters for the API or Registry modifies the behaviour of the runtime execution.
This provides us with the following benefits:
same code base, same binaries
change behaviour for a specific context
change behaviour at runtime
The installation profiles, as we tend to have many command line arguments, are encapsulated in a separate executable, this is called 't1c-launch'.
The 't1c-launc' does the following:
validate the environment
validate prerequisites
start the connector executables
provide the correct CLI params, decided upon compilation time
This document describes all achievable different scenario’s with pros and cons, depending on the business case.
To understand how the Trust1Connector can be setup, it is good to have an overview of all components in the Trust1Connector eco system.
The Trust1Connector can be installed in ‘offline’ mode. This is the case when:
no internet connection is available
no centralised Distribution Service is available/wanted
Following this approach, the installation base (devices with T1C installed) is managed from an software application distribution platform (version management, insights, …).
The Trust1Connector is fully functional in an offline environment and contains all module logic in the installation footprint. The options explained here describes what are the possible modes for offline installations.
Trusted browser and no PIN encryption between the browser and the connector application interface.
Untrusted browser and PIN encryption enforced through the connector application interface.
The Shared Registry executable is introduced to resolve client address ports during initialization. The shared registry runs a single instance on one of the connected clients OR the host application.
When the host is NOT running the shared registry, clients are dynamically checking if a registry is available. When a registry instance is not found, a random client launches a registry instance, untill the client becomes unavailable.
In this mode the Distribution Service is used for one or both of the following categories of use cases:
connector client instance synchronization
central port resolution
The former category denotes the device synchronization and management operational use cases.
The lattter adds to the functionality by acting as a central registry, becoming a critical component during connector client instance initialization.
In that scenario, connector instances are always bound to DS (Distribution Service); the DS is the centralized service handling the address port resolution for every client. A client will register it’s dynamically assigned port (from a configurable port range) at the DS. The DS resolves the address port for each web application trying to connect with it’s local client. The handshake is performed using an the web application consent flow.
The DS is a central service collection all anonimized operation data for every linked connector instance.
The DS serves the operational use cases:
demographic information
SSL and Device certificate rotation
client-demand log dispatching
CORS management
The communication from the web application towards the connector instance is secured and requires pre-requested JWT from the Distribution Service.
The local connector instances enforces JWT validation prior to use case execution.
Additional functionality for device key-rotation and application registry bindings are available in this context.
In this mode, DS communication is established but not blocking operationally once installed.
PIN Encryption and shared registry is configured on the host or on the client dynamically (local election algorithm). The shared registry stores a list of agents, keeping track of agents-port correlation.
The JWT authentication/validation on API is optional and configured during packaging.
An extension on the profile above, is when an admin runs the 'registry' process on-startup, as a service user, in a shared environment. This means that the registry process will run always, and will not be changed throughout user sessions (especially when a user session gets invalidated, or stays acive even when de user has logged out.
For shared environments, our recommendation is to start the registry process on a shared environment for all remote terminals/clients.
The DS keeps track of the client address ports and resolves the port upon every new session between the browser and the local connector instance during initialisation. Additionally the public key for web application encryption is shared between the registry and the requestion client application.
The variants decribed hereafter differs in how the packager stores the files and executables during installation.
In this mode, a user image is by default stateless and the connector is initialized upon every new user session.
This implies that the connector instance will register upon startup, for every new user login.
The user always starts with a clean installation when logged-in. This approach resembles with how Docker starts new images instances and can be used thus in a Docker image.
This variant is called ‘split installer’ and splits the location of the executables during installation and the user session related configuration files (transaction info, consent, device certificates, logs, …).
In this approach, the executables are provision in a predefined path (typically system program files or system folder).
The user session related files are stored in a user specific folder location.
provide an CLI param override mechanism, which is a pass-through for the overriden params to the executables (api/reg/sandbox)
An optional Local Registry for multi-host or shared environments.
It is required when using Trust1Connector on a shared machine with multiple users. The component is optional, and a central registry can be used as well. The integrating party must choose whether to opt for a local dynamic registry or a central Distribution Service Registry
T1C-Registry [Centralised]
An optional Centralised Registry for multi-host or shared environments. The service can only be used when a Distribution Service is provided in the solution architecture.
It is required when using Trust1Connector on a shared machine with multiple users. The component is optional, and a local dynamic registry can be used as well. The integration party must choose whether to opt for a decentralised or centralised approach. When choosing a centralised approach, a Distribution Service setup is needed.
T1C-DS
The Trust1Connector Distribution Server is a central management service for the T1C.
The DS is serving use cases for version management, demographic information, key rotation, additional security protection, dynamic CORS, application management and more
Virtual Reader
The remote loading implementation for a backend smart card service
The virtual card reader acts as a remote smart card reader, able to communicate with any card on a remote client enabling HSMs (High security modules), central card management systems, smart card personalisation use cases and more
API Gateway
An optional API gateway introduced when using the T1C-DS for security policy enforcement
As the T1C-DS acts as a REST microservice, additional security measurement must be taken into account. The API gateway implements different security policies applied on:
Device to DS communication
Application to DS communication
application application management
Component
Description
Note
T1C-SDK-JS
An easy to use Javascript SDK for quick integration into partner web applications
This is an optional component which can be used to ease and speed up the integration of the Trust1Connector into any web application. The SDK acts as an interface for the consuming web application and supports backwards compatibility
REST Client
A 3rd Party Rest client
Any REST client can be used to address the Trust1Connector use cases directly from your consuming application. Applications can be native desktop applications or web applications in any technology
T1C-Sandbox
A secured Sandbox for smart card APDU execution, exposing a gRPC interface
The Sandbox can be used directly for certain applications, but it’s main goal is to isolate the APDU interactions towards smart cards, and card readers (contact or contactless)
T1C-Rust-API
An OpenAPI REST interface, acting as an addressable microservice.
The local REST Service, installed on the local device, serving the functionality used directly from consuming applications or from the T1C-SDK-JS. The OpenAPI YAML is published and can be used to generate a REST client in any technology
T1C-Registry [Decentralised]