Architecture

signoSign/Universal as a whole is a Java web application whose task areas are divided into various Java servlets. These servlets are:

The servlet names refer to the content of the web.xml of the application.

The servlets SsuOpenServlet, SsuSecureServlet, and SsuSecureRestApi form a logical unit and are often grouped together as a Viewer. However, the term is also used to describe an instance of a Viewer into which a document is loaded. The Viewer is the core component of the application. The DevTools and document management are optional extensions that can be deactivated if required.

Persistence/database:
For technical reasons, signoSign/Universal requires a database that is compatible with the Java framework Hibernate. Depending on the application, however, no documents need to be saved in the database. Only advanced functions such as document sharing or the use of workflows require persisted documents. For this reason, the application is delivered with an H2 database that is started when the application is started if the database settings correspond to the delivery status. It is not recommended to use the H2 database in a productive system. The database is used by the Viewer component and the REST API. The REST API also forms the public interface to the database.

The Viewer:
The Viewer as a component works without persistence by loading a provided document into the main memory. Changes are only transferred to the loaded state if this is explicitly triggered by saving or where technically necessary, e.g. when a signature is started. During saving, the document can be transferred to the configured database or to an external system, depending on the application. It is also possible to do neither one nor the other when saving, and instead only update the document in the main memory in order to download and process the document yourself at a later time by integrating the REST API. Documents remain in the main memory as long as the session exists or until they are explicitly unloaded. The document is never required on the client side. The documents are never accessed and worked on directly on the PDF. On the client side, an exact representation of the actual PDF is always used in the form of rendered images of the pages and HTML forms. Changes are always made to the PDF on the server side.

The REST API:
The REST API interface is to be understood as part of the Viewer component and is always the recommended approach for integrators. The API is divided into thematic areas to facilitate orientation within the API. For example, there is an area for documents that is intended for uploading, downloading, and retrieving documents.

The document pool:
The document management, also known as the pool application, uses only the REST API interfaces of the Viewer and serves as a façade for the functional scope of the REST API.

User management:
Users are not managed directly within the application itself. Instead, two different approaches are available.

The first approach is to configure OIDC (OpenID Connect) in the application. This means that the users are managed via the corresponding provider. The user roles and authorizations are defined with the external identity provider.

Alternatively, the users can be provided via the server’s security realm. User information and access rights are then managed directly on the server. In both cases, users must be assigned suitable roles in order to be allowed to use the application.

The REST resource Users or User is available for user management. This resource can be used to perform various actions, such as changing user settings or retrieving data required to operate the application. It is also possible to delete users. It should be noted that deleting a user only resets the user account and does not prevent the user from continuing to use the application.