---
description: >-
  Running the Trust1Connector in a shared environment, such as Citrix, XenApp
  and Remote Desktop, requires additional installation steps. In this section we
  explain the concept and approach used.
---

# Concept

## Architecture Overview

The following schematic seems rather complicated as it explains the inner workings of the Trust1Connector components, the concept is elaborate further on this page. If you are only interested in what the integration impact is for your Web Application in a Shared Environment, you can skip directly to the section: [Integration in Web Applications](broken-reference)

![Component Diagram](https://1128878087-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fz2oJcMDLUVEPd3GcFUrT%2Fuploads%2FIsnClhGOWxzw4uJPA0jJ%2FV3_components_details_rust.jpg?alt=media\&token=7b8f285f-0898-4721-a341-95407b87268f)

## Components

### Web Environment

The Web Application can use the T1C-SDK-JS or a custom REST API client for integration purpose. As the Web Application operates in a browser context, resolving an agent, by means of a consent, will result in a browser cookie being provided.

The T1C-SDK-JS implements the detection of a Shared Environment during the initialisation of the library. When initialisation succeeds without a controlled exception, the setup is a standalone; when the initialisation throws an 401 Error, the T1C-SDK-JS can be used to request the user for a Consent.&#x20;

When using the REST API directly form your web application, reading the browser cookie and performing the initialisation must be done by the integrating Web Application itself.&#x20;

### Shared Environment Host

Compared to Trust1Connector v2, the v3 release has a separate component to be be installed on a shared host. This component is called the `T1C-Proxy` and only exposes the following use cases:

* Verify random available ports \[in a predefined range] which can be used by an Agent (Session of T1C-API running in user space)
* Port reservation upon installation of a new T1C-API in an active user session
* Port registration upon initialisation of a T1C-API in an active user session
* Management of an in-memory list of active Agents
* Management of user consents in a shared environment by means of browser cookies with an optional configurable TTL (time to live)

The `T1C-Proxy` operates by Default on the API port defined in the `T1C-DS` (Distribution Server). From a Web Application perspective, this is the only information known. When a Web Application requests the information of the device, the PROXY device type will inform the Web Application that the targeted underlying API is a PROXY, which means that the Web Application must ask for the Agent specific API port to configure an URI which can be used to execute the use cases.&#x20;

When using the `T1C-SDK-JS` this is done implicitly during initialisation.

### Shared Environment Client

A `T1C-API` installed for a specific users runs in \[User Space]. To avoid possible attack vectors, the Trust1Connector v3 will always run in \[User Space].

Upon installation of the `T1C-API`, during the post install phase, the `T1C-API` will try to verify automatically if it is running in a shared environment. If this is the case, the `T1C-API` will ask the T1C-Proxy for available ports and will reserve those post, prior to initialisation and startup.&#x20;

The ports which are reserved by the `T1C-Proxy` are the following:

* `T1C-API` Port: This is the port exposing the OpenAPI interface towards Web Applications and used by the `T1C-SDK-JS`

When receiving ports during post-install, an user agent device is temporary `RESERVED` in the Agent Registry of the `T1C-Proxy`. Upon T1C-API initialisation, the port configurations will be confirmed and the Agent Registry will set the device state on `REGISTERED`. From this moment on, a T1C-API instance, running in an active user session, will be available for the Web Application via the [consent flow](core/consent).&#x20;

The `T1C-gRPC` instance is inherently a component from the `T1C-API`, and thus is managed by the `T1C-API`.  As each user must have it's own hardened runtime for communication purpose, the port assigned for `T1C-gRPC` will be registered and configured by the `T1C-API` (and restarted when needed).

### Central Back-Office

Starting from this release (v3) of the Trust1Connector, each device must have a link with an active and running T1C-DS (Trust1Connector Distribution Server). This is to guarantee security, updates, and avoid potential risk in production.&#x20;

The T1C-DS is proceeded by an API Gateway who is managing the security offloading in the application layer. For a Web Application to communicate with a T1C-Proxy or T1C-API, a JWT (Json Web Token) is needed and obliged. The T1C-DS is responsible for the key management, the certificate management and other use cases which are described in a separate wiki.&#x20;

In order to retrieve a valid JWT, the T1C-DS can be requested from your application back-end with a valid api-key. The JWT is valid for a given amount of time, and sets the context used when requesting the T1C-API on a device.&#x20;

## Security

### Pin Handling

The PIN handling logic is implemented in the Trust1Connector API. More information on the basic and/or advanced rules can be found on the following link:

{% embed url="https://app.gitbook.com/@t1t/s/t1c-api/v/v3.5.0/concepts/pin-handling" %}

### Share Environment Flows

![](https://1128878087-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MA0NIpdSCJTdfFxKB45%2F-MCQAtUgRWPv2vZkQM0N%2F-MCQEhVKa7pbyfzmXf3R%2FV3_Shared_Env_Registration.jpg?alt=media\&token=7e50ee82-730b-490a-b25f-5aec153d23f3)



### Communication Stack



![](https://1128878087-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MA0NIpdSCJTdfFxKB45%2F-MCQG04eJzk5k5tXSeJv%2F-MCQGB9L4c6D2qw_xol2%2FV3_T1C%20Citrix.jpg?alt=media\&token=e13b442a-cb1c-48da-a796-f1cc183d81e2)
