PC - Integration into customer's infrastructure

Introduction

PC is a software solution to confirm or sign digitally transactions in digital banking and/or electronic document management (e-docflow) systems.
The primary purpose of PC is to create a better customer experience and increase security level compared to SMS, one-time passwords (OTP) solutions, scratch cards, MAC tokens and etc.
PC can be used to confirm declarations of intention in digital banking transactions, authentication, creation and execution of documents, facts of receiving and/or reading a certain document.

Component parts

PC consists of following parts:

# Part Description
Server PC Server PC Server is an application for back-end installation. PC Server functions can be accessed by the application system with calls to PC Server web services via REST API. This enables integration with any application platforms.
PC Server must be installed within the security perimeter of the application system.
This component is integrated with the server part of digital banking or e-docflow system and performs the following functions:
  • PC users’ registration;
  • PC users’ key information generation and updates;
  • Transaction confirmation operation;
  • Billing and data reports generation.
    		•
    PC External PC External is an application to be installed in back-end's DMZ. PC External functions are not accessed by the application system. It interacts with PC Server on one end and with the client app on the other.
    Includes such function as:
  • User devices’ registration;
  • Provision of transactions information to be confirmed by the user;
  • Transactions confirmation (digital signature) receive and verification via PC Server
    		•
    PC Pusher PC Pusher is an application to be installed in back-end or DMZ. PC Pusher functions are not accessed by the application system. It only communicates with the PC Server.
    Sends transaction confirmation push notifications to the mobile app.
    PC Server Signer PC Server Signer is an application for back-end installation. It works on behalf of Client mobile app - performs holding keys, transaction confirmation, etc., but it's managed by application system. This component is used to build signing scenarios, completely managed by application back-end.
    PC Conflicts Resolving Tool (CRT) PC CRT is an application for back-end installation. It provides web-based User Interface to get detailed information about PC Users, Transactions, Confirmations, Devices, etc. Also it generates reports to be provided to conflicts resolving commissions as proving materials.
    Client PC Mobile SDK / PC App Performed as a mobile application for iOS 12 (and above) and Android 7 (and above) with the following functions:
  • Users and keys management in a mobile app (read, storage, use, update, delete);
  • Transaction details receiving in online or offline modes;
  • Transaction details performance on a smartphone’s screen for client’s confirmation;
  • Digital signatures generation on the basis of cryptographic transformation of transaction details, user keys, a timestamp and (optionally) a device fingerprint (based on key device parameters);
  • Digital signatures transmission to the server component in online mode or a confirmation code display to the user in offline mode.
    • The client component can be performed as a standalone application as well as a set of embedded libraries to be integrated into a mobile app.

    See Figure 1 for the component interaction diagram.

    component_interaction_diagram.svg

    Server component supply options

    PC server components can be supplied as Java applications (JAR-files) containing PC Server modules, that run as standalone Java applications.

    JAR-files launch web-server (Tomcat) and PC component itself inside it.

    Configuration is performed via configuration files and database (for PC Server only).

    The recommended option is to install Java applications on virtual machines (or containers) provisioned by the customer according to the organization's internal needs. Virtual infrastructure (or containers) also offers a better option for scaling, backup and restore in case of system failures.

    Typical machine components

    A typical machine (or a container) consists of the following installed components:

    Component Description
    Operating system Linux-based
    Application server operation environment Java 17+
    DBMS PostgreSQL

    All the PC components are launched automatically with the operating system. No manual settings for start/shutdown is required.

    If neither a physical nor virtual servers are supplied, the OS preparation is carried out by the customer. Preparation includes:

    • Installation of the operating system;
    • Proper configuration of DNS records;
    • Installation of the Java Runtime Environment;
    • Preparing TLS certificates (if necessary).

    The following alternative components can be used:

    Component Description
    Operating system Microsoft Windows
    Application server operation environment Java 17+
    DBMS Microsoft SQL Server 2012/2014/2016, Oracle DB 11g/12c/18c

    OS and DBMS licenses and the DBMS (one of the options) are provided by the customer.

    The DBMS must provide DB scaling and fail-safe features. If a non-PostgreSQL DBMS is used, connection options and DBMS type must be considered accordingly.

    If a non-PostgreSQL DBMS is used, connection options and DBMS type must be consistent with each other.

    PC server components

    The PC Server component is logically separated into the following parts:

    • PC Server used to communicate with the application system within the controlled security zone.
    • PC Pusher used to send push-notifications to Google, Apple and Huawei servers over the Internet (it initiates outbound https connections). Push notifications is not mandatory for PC, and this component is optional.
    • PC External used to communicate with the client component over the Internet (it accepts incoming https connections).
    • (Optional) PC Server Signer emulates actions on behalf of PC user to make a server-side signature without a mobile device.
    • (Optional) PC CRT is a web-based UI to get detailed information about entities and events in PC.

    Each part of the PC server component can be installed either individually or in combination with any other component. See Figure 2 for the component interaction diagram and the recommended logical configuration.

    Push notifications addresses

    PC Pusher Server requires network access to the following addresses to send push-notifications:

    Service DNS names and ports
    Apple Push Notification Services
    (iOS push-notifications)    		 https://api.push.apple.com
    Google Firebase
    (Android push-notifications)    		 https://fcm.googleapis.com
    https://www.googleapis.com
    https://oauth2.googleapis.com
    https://accounts.google.com
    Huawei Messaging Services
    (Huawei push-notifications)    		 https://push-api.cloud.huawei.com
    https://oauth-login.cloud.huawei.com/oauth2/v3/token

    Integration options

    Connections specified as HTTP in the diagrams can be replaced with HTTPS as required.

    Default incoming TCP ports are specified in the diagrams. They can be changed if necessary.

    Callback address can be specified in PC settings or can be generated by the Application for each transaction when the transaction is created. You can contact the manufacturer or the Application support organization for the up-to-date parameter values.

    Separated

    See Figure 2 for the recommended integration diagram of completely separated components into the infrastructure.

    infrastructure-separated.svg

    Combined

    PC Server and PC Pusher on the same machine

    If in accordance with the company’s internal rules the infrastructure configuration does not block access to certain Internet resources from the server segment of the network, then the PC Server and the PC Pusher can be deployed on the same machine within the perimeter. In this case, the component diagram will be as shown in Figure 3.

    Principal requirement: servers that send push notifications (Apple Push Notification Services, Google Firebase and Huawei Mobile Services) must have access to push-servers.

    infrastructure-combined-pcs-pusher.svg

    PC Pusher and PC External on the same machine

    PC Pusher and PC External can be deployed on the same server if the customer installs and configures an URL filter for incoming request (including TLS) before them from the side of the Internet (Figure 4).

    infrastructure-combined-external-pusher.gsvgif

    Test installation

    For testing purposes, when only simulated (test) data are used, all the three server components and the conflict resolution workstation can be deployed on the same machine (Figure 5).

    infrastructure-combined-all.svg

    Interaction with application systems

    Calls to PC Server web services over the HTTP protocol are used to interact with application systems. Default port is 8080.

    If HTTPS is used, the default port is 8443.

    Customization options

    Internal database deployed on a machine with the PC Server or a remote database can be used to store information.

    Resiliency and scaling

    Application Server redundancy

    Resiliency

    If an external database with its own resiliency mechanism is used, redundancy is only required for the application server which runs the functional web services of the PC component. Requests to functional web services can be handled by one or several machines.

    See Figure 6 for the redundancy diagram.

    drp-1.svg

    The DBMS itself is to provide DBMS availability and redundancy.

    Scaling

    Two ways of scaling can be used in this configuration:

    1. By increasing the computing power of the virtual or physical machine of the PC server component;
    2. By increasing the number of virtual or physical machines that handle requests for functional web services.
      A customer-provided and customer-configured balancing component must carry out load balancing between the machines and monitor the availability of each machine.

    Complete redundancy

    Resiliency

    If an internal DBMS is used, redundancy must be achieved via hot or cold backup of the entire virtual or physical machine of the PC component. In this case, requests to functional web services must be handled at a single machine at any specific time.

    Regular replication is required for the backup copy to be up-to-date at all times.

    See Figure 7 for the redundancy diagram.

    drp-2.svg

    Scaling

    In this case, scaling is achieved by increasing the computing power of the virtual or physical machine.