Architecture

Description

The example system, presented in the diagrams, consist of two main domains: the Customer Domain and the Provider Domain. Diagrams illustrate the process by which a customer uses a business application to seal the document using services provided by SIGNIUS in multiple different setups.

Components

• Driving/Business Application - a business application used by the customer to initiate the process of sealing documents.

• Network folder - a path to directory where document sealing exchange is being performed.

• SIGNIUS Sealing Client - a sealing solution client application of the system responsible for communication with the SIGNIUS Sealing Server (and in case of smartcard setup, also responsible with communication with card/card reader) and processing data necessary for sealing documents.

• SIGNIUS Sealing Server - a sealing solution server application of the system responsible for communication with QSCD, QTSP and database server.

• QSCD (Qualified Seal/Signature Creation Device) - a qualified signature creation device that ensures process security.

• Remote QTSP (Qualified Trust Service Provider) - a remote trust service provider service that provides a qualified timestamp and validation.

• Database server - SQL server holding process configuration.

Security and communication

Communication between the SIGNIUS Sealing Client and the SIGNIUS Sealing Server and between the SIGNIUS Sealing Server and the QSCD/QTSP is secured using HTTPS, which ensures the confidentiality and integrity of transmitted data. The use of the HTTPS protocol and trusted components such as QTSP and QSCD guarantees a high level of security in the process of document verification and sealing.

The system is a comprehensive solution for generating and verifying digital seals, integrating the client's business applications with advanced cryptographic services provided by SIGNIUS and external partners.

🏛️ Hosted Setup

Flow

• The customer's business application transmits data to the SIGNIUS Sealing Server via REST API.

• SIGNIUS Sealing Server returns a document hash (DocHash) in case of single documents and in case of batches of documents returns documents package with already embedded signature/seal into them via REST API.

🏛️ Hybrid Setup

Flow

• The customer's business application transmits data to the SIGNIUS Sealing Client via REST API or using preconfigured filesystem directory (whether it is network or local folder).

• SIGNIUS Sealing Client requests document sealing with integrated SIGNIUS Sealing Server using REST API.

• SIGNIUS Sealing Server assembles signature/seal and raw document into a document with embedded signature/seal (sealed document).

• SIGNIUS Sealing Server returns to SIGNIUS Sealing Client with already embedded signature/seal into document using REST API.

• SIGNIUS Sealing Client provides sealed document to customer's business application using exchange method which began the whole process (FILESYSTEM or REST).

🏛️ On-premise Setup

Flow

• On-Premise setup combines all possible flows of both Hosted and Hybrid setups but entirely within the customer domain. With correct configuration of the environment there is almost no need for any connection to move outside the bounds of organization's network which creates highly secure system.

🏛️ Smartcard Setup

This version of Smartcard setup has the same set of functions as Hybrid but it is a bit harder to configure and when using Smartcard instead of HSM for encryption it provides lower speed and lower level of protection/security.

Flow

• Like in Hybrid setup, request for sealing document is initiated by driving application and is passed to SIGNIUS Sealing Client

• SIGNIUS Sealing Client instead of passing request to SIGNIUS Sealing Server, uses certificate located on smartcard (available at client's machine via card reader) to assemble signature/seal (from this certificate) and raw document into a document with embedded signature/seal (sealed document)

• *SIGNIUS Sealing Client can additionally send sealed document to SIGNIUS Sealing Server to add timestamp - depends on process configuration

• finally returns sealed document using exchange method which began the whole process.

Flow

• This version of Smartcard setup has the same set of functions as On-Premise but it can also use Smartcard in addition to or instead of HSM for encryption of selected processes.