Sample code uses ES6 language features such as arrow functions and promises. For compatibility with IE11, code written with these features must be either transpiled using tools like Babel or refactored accordingly using callbacks
Chambersign is only usable when the Middleware software has been installed. As integrator you can check this with the File Exchange module. Example will be described below
Chambersign introduction
The Chambersign token is a token that requires for the middleware of Chambersign to be installed prior to using it on the Trust1Connector.
Detect if Middleware has been installed.
Windows
The chambersign software for windows requires administration rights to be installed. After installation the location will be:
x64 & x86 ; C:\Program Files\ChamberSign
To check if this has been installed we can use the File-exchange create type function and then check the contents of the (sub)-folders.
To check if the middleware is installed the sample code below is a good start to use the File-Exchange to check if the middleware has been installed and its safe to continue to use the ChamberSign middleware and the Trust1Connector.
This is an example of how this could be integrated. You are free to implement this however you like. Information for the file-exchange module can be found here
constentity="chambersign";consttype="middleware";constinitPath="C:\\Program Files\\ChamberSign"T1CSdk.T1CClient.initialize(config).then(res => { client = res; core =client.core();let fileex =client.fileex();constmiddlewareInstalled=awaitisMiddlewareInstalled(fileex);if (middlewareInstalled) {// Middleware is installed you can use the chambersign token with the T1C } else {// Middleware not installed please install before using it with the T1C }}, err => {errrorHandler(err);});asyncfunctionisMiddlewareInstalled(fileexClient) {fileexClient.existsType(entity, type).then(existsRes => {if (existsRes.data) {// Type existsreturncheckFilesPresent(fileexClient); } else {// Type does not exist fileexClient.createType(entity, type, initPath).then(createRes => {returncheckFilesPresent(fileexClient); }, err => {errrorHandler(err); }) } }, err => {// Type exists error, try to create and then check if middleware is installedfileexClient.createType(entity, type, initPath).then(createRes => {returncheckFilesPresent(fileexClient); }, err => {errrorHandler(err); }) });}asyncfunctioncheckFilesPresent(fileexClient) {awaitfileexClient.existsFile(entity, type,"HashLogic\\bin\\idoPKCS.dll").then(existsFileRes => {return existsFileRes; }, err => {returnfalse; })}
Because we're using the generic interface we can define the module variable upfront since we know we want to use the chambersign integration.
Certificates
Exposes all the certificates publicly available on the smart card.
Authentication Certificate
Contains the 'authentication certificate' stored on the smart card. The 'authentication certificate' contains the public key corresponding to the private RSA authentication key. The 'authentication certificate' is needed for pin validation and authentication. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not
The service can be called:
{"certificate": {"certificate":"MIIFjjCCA3agAwIBAgIIO...xg==","parsedCertificate": {...} },// OR if multiple certificates"certificates" [ {"certificate": {"certificate":"MIIFjjCCA3agAwIBAgIIO...xg==","parsedCertificate": {...} } } ]}
Non-repudiation Certificate
Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not
The service can be called:
The 'algorithm_reference' property can contain the following values: sha1, sha256, sha512, md5.
The core services lists connected readers, and if they have pin-pad capability. You can find more information in the Core Service documentation on how to verify card reader capabilities.
Bulk Signing
It is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk parameter set to true to the request. Subsequent sign requests will not require the PIN to be re-entered until a request with bulk being set to false is sent, or the Bulk Sign Reset method is called.
When using bulk signing, great care must be taken to validate that the first signature request was successful prior to sending subsequent requests. Failing to do this will likely result in the card being blocked.
When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:
var data = {"pin":"..."}generic.verifyPin(module, data, callback);
Response:
{"verified": true}
Verify PIN with pin-pad
When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:
var data = {}generic.verifyPin(module, data, callback);
Response:
{"verified": true}
Authentication
The T1C-GCL is able to authenticate a card holder based on a challenge. The challenge can be:
provided by an external service
provided by the smart card
An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
External Challenge
An external challenge is provided in the data property of the following example:
var data = {"pin":"...","algorithm_reference":"sha1","data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E="}generic.authenticate(module, data, callback);