Getting started

1. Zamna Client integration scheme

Airline is required to deploy and configure the Zamna Client stack within its own infrastructure (on-prem or Cloud). Zamna Client then provides APIs, callable from within the Airline existing business processes and touch-points.

Crucially, no personal data is ever stored or exposed from Airline security premises using Zamna. Through the installation process, network and firewall configuration is updated to allow Zamna Client to communicate with the Zamna Cloud and other authenticated Trusted Peer Nodes.

Integration with PSS

Depending on the desired integration flow, Zamna Client can connect to Airline PSS (Altea, Navitaire, Sabre, etc.) via existing APIs/Web-services:

• get booking/PNR and passenger data (including passport, if is in DCS)
• set passport (APIS) data
• add/remove documents
• set/unset documents as verified
• (optional) set and remove SSRs
• (optional) set and remove HPCs

Zamna Client provides APIs for Airline own applications/touch-points to interact with:

There are 2 high-level APIs available:

• Checklist API
• Ready To Fly API

2. Zamna Client stack overivew

The Zamna Client stack comprises following components:

• ApiServer — Kotlin/Java Server Application running on javalin (opens new window), serving the main functionality and Zamna Client APIs,

• Database — a PostgreSQL database, where only operational (not personal) data is stored (under Airline full management and control),

Optional components/modules:

• WebView — customer (passsenger) facing frontend Single-Page Application,

• ID documents processing — a module to verify and extract data from ID documents,

• PDF documents processing — a module to verify and extract data from PDF documents (e-Visas, etc).

Zamna Client stack supports horisontal scaling — additional ApiServer instances can be added to the cluster when required:

3. Technical requirements

We recommend the following specifications for a host machine running ApiServer instance:

• 2x 3.1 GHz CPU
• 4 Gb Mem

For the Database instance we recommend the following minimum requirements:

• DB size: 200Gb
• vCores/CPUs: 2
• IOPS: 1000

We recommend the following specifications for a host machine running PDF documents processing instance:

• 2x 3.1 GHz CPU
• 4 Gb Mem

4. Installation

4.1. Create credentials

In collaboration with Zamna implementation support engineers, Airline generates (locally, or as part of the pipeline) a set of credentials required to interact securely with the permission-ed network. As part of our procedures, these credentials are regularly renewed.

To generate everything needed to facilitate the connection, replace org_name_here (e.g. "utopiaair") and org_domain_here (e.g. "com.airutopia") with relevant values and run the following command:

Please note

org_name_here should only contain alphanumeric symbols, and org_domain_here should be valid domain name you are in control of

TIP

For Debian, use -d instead of -D for base64

TIP

For Windows, use the B64 tool available on GitHub (opens new window) for base64 encoding

Staging

docker pull zamna/fabricartifacts:staging
docker run -e ORG_NAME=org_name_here -e ORG_DOMAIN=org_domain_here zamna/fabricartifacts:staging | base64 -D > output.tar.gz

Production

docker pull zamna/fabricartifacts:production
docker run -e ORG_NAME=org_name_here -e ORG_DOMAIN=org_domain_here zamna/fabricartifacts:production | base64 -D > output.tar.gz

This will create output.tar.gz file.

To unarchive it, run:

tar -xf output.tar.gz

This will create the output folder consisting of:

• crypto-config folder — contains all cryptographic materials for your organisation. This folder needs to be saved securely — it’s very important not to lose these files.
• org-config.json — organisation definition of your organisation.
• connection.yaml — credentials for a connection to decentralised network.

Also, your public keys:

• sign_public_key.pem

• auth_public_key.pem

• webserver_auth_public_key.pem

And your private keys:

WARNING

⚠️ Keep private keys secure and never share it with anyone, including Zamna

• sign_key.pem

• auth_key.pem

• webserver_auth_key.pem

TIP

Keep secrets in Secret Managers for Cloud deployments (e.g. AWS KMS/Secrets Manager, Azure Key Vault, etc.) and expose them from Secrets Manager to Zamna Client container as environment variables

4.2. Network and Firewall configuration

ApiServer requires access to the following URLs:

Staging environment

• apiserver.staging.zamna.com
• checklist-stats.staging.zamna.com
• name-matching-stats.staging.zamna.com
• rules-engine.staging.zamna.com
• cloudwatch.eu-west-1.amazonaws.com
• logs.eu-west-1.amazonaws.com

Production environment

• apiserver.production.zamna.com
• checklist-stats.production.zamna.com
• name-matching-stats.production.zamna.com
• rules-engine.production.zamna.com
• cloudwatch.eu-west-1.amazonaws.com
• logs.eu-west-1.amazonaws.com

Access to Airline services and APIs

If the integration flow requires Zamna Client to connect to Airline own services and APIs (ie DCS), it will also require access

4.3. Deploy Zamna Client stack

TIP

Zamna Client stack can be deployed in several ways: ranging from simple Docker images to Terraform/Kubernetes scripts or Ansible playbooks - depending on existing Airline infrastructure, restrictions, and IT strategy/policy.

Zamna's implementation engineers will undertake an initial technical scoping to ensure the fastest and easiest deployment option is selected and will provide all required materials and ongoing live support.

General deployment process

Zamna will provide access to its private Docker images repository (Dockerhub or AWS ECR) — Docker images of all the Zamna Client stack components can be pulled to an Airline own container registry (eg AWS ECR/Azure ACR), from where they can be utilised as part of the CI/DI pipeline.

Additionally, Zamna can configure its own CI/DI pipeline to push new versions of images directly to Airline own image repositories.

4.3.1. (optional) Deploy ID documents processing module

Zamna is integrated with a number of ID & online document verification platforms out of the box. Either Airline have pre-existing partnerships, so Zamna Client can utilise it - or Zamna can source required functionality from a rouster of pre-approved and fully integrated solutions.

4.3.2. (optional) Deploy PDF documents processing module

The module is distributed as Docker image.

AWS ECR

230436152505.dkr.ecr.eu-west-1.amazonaws.com/data-extractor

Dockerhub

zamna/data-extractor

No additional configuration is required.

4.3.3. Deploy ApiServer

Note

ApiServer requires access to:

• Database
• ID documents processing (if used, for Ready To Fly)
• PDF documents processing (if used, for Ready To Fly)
• DCS (for Ready To Fly)

The module is distributed as Docker image.

Checklist API configuration

AWS ECR

230436152505.dkr.ecr.eu-west-1.amazonaws.com/checklist-app

Dockerhub

zamna/checklist-app

Ready To Fly API configuration

AWS ECR

230436152505.dkr.ecr.eu-west-1.amazonaws.com/paxcheck-app

Dockerhub

zamna/paxcheckapp

The following environment variables should be injected into the container from Secrets Manager:

• AUTH__PRIVATE_KEY — base64 encoded contents of auth_key.pem file

• SIGNALS__WRITE__SIGNING_PRIVATE_KEY — base64 encoded contents of sign_key.pem file

• SIGNALS__WRITE__DELETION_SECRET — base64 encoded string (min 32 bytes)

• SERVER__AUTH_SECRET_KEY — base64 encoded contents of webserver_auth_key.pem file

• AIRLINE_ENCRYPTION_CONFIG__KEY — AES key for booking identifiers encryption

• AIRLINE_ENCRYPTION_CONFIG__IV — AES IV for booking identifiers encryption

Additionally, driven by an Airline environment and setup, Zamna will provide a personalised configuration.yaml file to be placed inside the container — from which ApiServer reads its configuration.

4.3.4. (optional) Deploy WebView

The module is distributed as Docker image — as design/UX is personalised for each Airline, Zamna will provide access to a dedicated WebView Docker image.

No additional configuration is required.