Architecture

signoSign/Universal as a whole is a Java web application, with task areas divided into different Java servlets. These servlets are:

The SsuOpenServlet, SsuSecureServlet and SsuSecureRestApi servlets 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 that a document is loaded into. The Viewer is the core component of the application. The DevTools and document management are optional extensions that can be disabled if required.

Persistence/database:
For technical reasons, signoSign/Universal requires a database that is compatible with the Java framework Hibernate. However, depending on the application, it may not be necessary to store any documents in the database. Only advanced functions such as document sharing or the use of workflows require persistent documents. For this reason, the application is supplied with an H2 database, which is started when the application is launched if the database settings correspond to the preset state. 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 component operates without persistence by loading a provided document into the working memory. Changes will only be transferred to the loaded state if this is explicitly triggered by saving or if this is technically necessary, e.g. when a signature is started. When saving, the document can either be transferred to the configured database or to an external system, depending on the application. It is also possible to do neither when saving, but instead to update the document in the working memory only, so that you can download and process the document yourself at a later point by integrating the REST API. Documents remain in the working memory for as long as the session lasts or until they are explicitly unloaded. The document is never required on the client side. Accessing and working on documents is never done 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. The 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 make it easier to navigate within the API. For example, there is an area for documents that is intended for uploading, downloading and querying documents.

The Document Pool:
Document management, also known as the pool application, uses only the Viewer’s REST API interfaces and serves as a façade for the REST API’s range of functions.

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 users are managed via the relevant provider, with user roles and permissions defined in the external identity provider.

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

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