Architektur
signoSign/Universal als Ganzes ist eine Java-Webapplikation, deren Aufgabenbereiche in verschiedene Java-Servlets aufgeteilt sind. Diese Servlets sind:
Servlet-Name | Beschreibung |
|---|---|
SsuOpenServlet | Verarbeitung von Anfragen für systemfremde Benutzer im Viewer. Dazu gehören Anfragen ohne Authentifizierung oder die Bearbeitung von geteilten Dokumenten. |
SsuSecureServlet | Verarbeitung von Anfragen Authentifizierter Sessions im Viewer. |
SsuSecureRestApi | Verarbeitung von Anfragen an die REST-API. |
DevTools | Bereitstellung von Hilfsmitteln für Integratoren. (optional) |
Pool | Bereitstellung einer Dokumentenverwaltung. (optional) |
Die Servlet-Namen beziehen auf den Inhalt der web.xml der Anwendung.
Die Servlets SsuOpenServlet, SsuSecureServlet und SsuSecureRestApi bilden eine logische Einheit und werden häufig als Viewer zusammengefasst. Der Begriff wird aber auch verwendet, um eine Instanz eines Viewers zu beschreiben, in die ein Dokument geladen wird. Der Viewer ist die Kernkomponente der Anwendung. Die DevTools sowie die Dokumentenverwaltung sind optionale Erweiterungen, die bei Bedarf deaktiviert werden können.
Persistenz/Datenbank:
Aus technischen Gründen benötigt signoSign/Universal eine Datenbank, die mit dem Java-Framework Hibernate kompatibel ist. Je nach Anwendungsfall müssen jedoch keine Dokumente in der Datenbank gespeichert werden. Erst erweiterte Funktionen wie das Teilen von Dokumenten oder die Verwendung von Workflows erfordern persistierte Dokumente. Aus diesem Grund wird die Anwendung mit einer H2-Datenbank ausgeliefert, die beim Start der Anwendung gestartet wird, wenn die Datenbankeinstellungen dem Auslieferungszustand entsprechen. Es wird nicht empfohlen die H2-Datenbank in einem Produktivsystem zu verwenden. Die Datenbank wird von der Viewer-Komponente und der REST-API verwendet. Die REST-API bildet auch die öffentlich Schnittstelle zur Datenbank.
Der Viewer:
Der Viewer als Komponente arbeitet ohne Persistenz, indem ein bereitgestelltes Dokument in den Arbeitsspeicher geladen wird. Änderungen werden werden nur dann in den geladenen Zustand übertragen, wenn dies explizit durch das Speichern ausgelöst wird oder es technisch notwendig ist, z.B. beim Starten einer Signatur. Beim Speichern kann das Dokument je nach Anwendungsfall in die konfigurierte Datenbank oder in ein externes System übertragen werden. Es ist auch möglich, beim Speichern weder das eine noch das andere zu tun, sondern das Dokument nur im Arbeitsspeicher zu aktualisieren, um das Dokument durch eine Integration der REST-API zu einem späteren Zeitpunkt selbst herunterzuladen und zu verarbeiten. Dokumente verbleiben im Arbeitsspeicher solange die Session besteht oder sie explizit entladen werden. Clientseitig wird in keinem Fall das Dokument benötigt. Der Zugriff und die Arbeit an den Dokumenten erfolgt nie direkt auf dem PDF. Clientseitig wird immer mit einer genauen Repräsentation des eigentlichen PDF in Form von gerenderten Bildern der Seiten und HTML-Formularen gearbeitet. Das Einbringen der Änderungen in das PDF erfolgt immer serverseitig.
Die REST-API:
Die REST-API-Schnittstelle ist als Teil der Viewer-Komponente zu verstehen und ist immer der empfohlene Ansatz für Integratoren. Die API ist in thematische Bereiche unterteilt, um die Orientierung innerhalb der API zu erleichtern. So gibt es beispielsweise einen Bereich für Dokumente, der für das Hochladen, Herunterladen und Abfragen von Dokumenten vorgesehen ist.
Der Dokumentenpool:
Die Dokumentenverwaltung, auch Pool-Anwendung genannt, nutzt ausschließlich die REST-API-Schnittstellen des Viewers und dient als Fassade für den Funktionsumfang der REST-API.
Benutzerverwaltung:
Die Verwaltung der Benutzer erfolgt nicht direkt innerhalb der Anwendung selbst, sondern es stehen zwei verschiedene Ansätze zur Verfügung.
Der erste Ansatz besteht darin, OIDC (OpenID Connect) in der Anwendung zu konfigurieren. Dadurch werden die Benutzer über den entsprechenden Anbieter verwaltet. Hierbei werden die Benutzerrollen und -berechtigungen beim externen Identity Provider festgelegt.
Alternativ dazu können die Benutzer über den Security-Realm des Servers bereitgestellt werden. Dabei werden die Benutzerinformationen und Zugriffsrechte direkt auf dem Server verwaltet. In beiden Fällen müssen den Benutzern geeignete Rollen zugewiesen werden, um die Anwendung nutzen zu dürfen.
Für die Benutzerverwaltung stehen die REST-Ressource Users bzw. User zur Verfügung. Mithilfe dieser Ressource können verschiedene Aktionen durchgeführt werden, wie beispielsweise das Ändern der Benutzereinstellungen oder das Abrufen von Daten, die für den Betrieb der Anwendung notwendig sind. Es besteht auch die Möglichkeit, Benutzer zu löschen. Dabei ist zu beachten, dass das Löschen eines Benutzers lediglich den Benutzeraccount zurücksetzt und nicht verhindert, dass der Benutzer weiterhin die Anwendung nutzen kann.