Initialisation
Description of how to initialise the T1C via API
Introduction
The Trust1Connector is a program that has 3 components that function together to create a coherent experience to interact with hardware readers and cards.
API
Registry
Sandbox
API
The API component is the main communication channel. This is used to ask information from a specific hardware device or send specific commands.
Registry
The Registry component is one that is available for each system. This takes care of keeping multiple API components active and available on the system.
Users can communicate with the registry to retrieve the correct configuration which holds information such as the TCP port to be used to contact the correct API.
This components is crucial to support multi-user environments such as Citrix, terminal server, RDP, ...
Sandbox
The sanbox is a component that takes care of all the lower level communication with the hardware components. The sandbox is directly used and managed by the API.
initialisation flow
Initialising the Trust1Connector can be done by following the flow described in the picture below
Check local consents
The first step in the initialisation is to check if the browser/user already has a consent present.
Based on this information we know if we either have to call for a new consent or just validate if the existing consent is correct and usable.
Local consent present
If we already have a consent present in the user's local storage we can ask the registry to validate them before we actually use them.
To validate your consents you can give them with the Validate endpoint as described below
Validate existing consents
POST
https://t1c.t1t.io:51983/v3/validate
Validate existing consents to check if they have not exceeded the validity and if they are targetting the correct config.
Headers
Name | Type | Description |
---|---|---|
X-CSRF-Token* | String | t1c-js |
Content-Type* | String | application/json |
Request Body
Name | Type | Description |
---|---|---|
consents* | Array | Array of already existing consents |
This endpoint will either return with consentState
APPROVED
or REQUIRED
. Keep in mind it will always return the active list of consents you need to keep in your local list of consents.
Local consent not present or consent is required
If you do not have any consents locally or the Validate returned with REQUIRED
you will have to provide a new consent.
To provide a consent you will need to create a randomised string value and let the user put this on his/her clipboard. You can do this via a JavaScript call that is triggered behind a button in the user interface.
After this is done you can now execute the consent endpoint providing the randomised string that is put on the user's clipboard as body data.
Ask for a new consent
POST
https://t1c.t1t.io:51983/v3/consent
Based upon a random string on the user's clipboard we want to receive a new, valid consent.
Headers
Name | Type | Description |
---|---|---|
X-CSRF-Token* | String | t1c-js |
Content-Type* | String | application/json |
Request Body
Name | Type | Description |
---|---|---|
codeWord* | Strig | Codeword that was placed on the user's clipboard |
If a users gets the consent required message after trying more then 2 times this means that the registry could not find that specific instance of the user.
This could indicate that this user does not have the Trust1Connector running or the value was not placed on his clipboard.
When the consent was successfull we store the list of consents in the local storage (for next time) and use the consent
value to retrieve our configuration.
Parse the active consent
When either the validate or consent methods return succesfully we can use the consent
property, which is the active consent to retrieve our configuration properties.
This includes the agent username
, hostname
, pid
, sandbox
information
,...
but most importantly this holds the apiPort
property which is the actively running port of the user's Trust1Connector API.
To retrieve this information we need to parse the active consent
which is a base64
encoded JSON object.
The original value looks like this;
After base64 decoding you will receive a JSON object which looks like this;
With this information we can now use the apiPort
contact the API directly and the initialisation of the Trust1Connector is finished.
The endpoint below is contacting the Trust1Connector API with the correct apiPort
Get the information of the Device
GET
https://t1c.t1t.io:55001/info
Retrieve the Trust1Connector API info
Last updated