Lösungsstrategie

Architekturprinzipien

Modularität:

Um eine bessere Wartbarkeit und Skalierbarkeit zu gewährleisten, ist die Anwendung auf verschiedene Services und Komponenten aufgeteilt.
Folgende Abbildung zeigt die Aufteilung der Anwendung in Frontend- und Backend-Anwendung, Datenbank und Identity-Provider:

architecture-beta
    group elego(server)[elego]
    group cloud(internet)[cloud]

    service frontend(server)[elego Frontend] in elego
    service backend(server)[elego Backend] in elego
    service db(database)[Database] in elego
    service idp(server)[IDP] in cloud

    frontend:R --> L:backend
    backend:R --> L:db
    idp:T <-- B:frontend
    idp:T <-- B:backend

Hold "Alt" / "Option" to enable pan & zoom

Flexibilität

Um die unterschiedlichen Anforderungen unser Kunden zu erfüllen, ist elego auf Flexibilität ausgerichtet:

• Der Zugriff auf die Datenbank wird über ein Persistenz-Framework sichergestellt. So können verschiedene DBMS verwendet werden.
• Backend-Module haben klar definierte Schnittstellen. Dadurch können sie bei Bedarf durch individuelle Implementierungen ersetzt werden.
• Prozesse und Oberflächen sind individuell parametrierbar und können als gesamtes Parametrierung-Package exportiert/importiert werden.

Langlebigkeit

Bei der Auswahl von Technologien wird auf Langlebigkeit geachtet.

Sicherheit

Zum Schutz von Vertraulichkeit, Verfügbarkeit und Integrität sind folgende Massnahmen umgesetzt:

Anforderung	Lösung
Authentifizierter Zugriff	Zugriff auf die Anwendung haben nur authentifizierte Benutzer. Die Authentisierung eines Benutzers erfolgt über einen OpenID Connect fähigen IDP (IdentityProvider).
Autorisierung von Funktionen	Die Autorisierung ist rollen basiert. Jeder Funktion (GUIs, Prozesse und Commands) kann die zur Ausführung benötigte Berechtigungen hinterlegt werden.
Sichtbarkeits-Beschränkung (Mandanten-Fähigkeit)	Jede Fach-Entität kann einem Tenant (Mandant) zugewiesen werden. Nur Benutzer, die für den Tenant berechtigt sind, haben Zugriff auf die Entität.
Schutz von Data in Transit	Daten werden ausschliesslich per HTTPS (TLS >= 1.2) übertragen
Schutz von Data in Rest	Anwendungsdaten werden an definierten Orten abgelegt. Diese sind vom Betreiber gegen unautorisiertem Zugriff zu schützen. Sind die Daten auf der Datenbank zu verschlüsseln, ist das mit Transparent data encryption (TDE) möglich. Der Performance-Impact ist gemäss Microsoft 3-5%
Nachvollziehbarkeit	Jede Business-Transaktion wird protokolliert. Für jede Entität ist parametrierbar, ob eine lückenlose Historie (Datum der Änderung, Bearbeiter, alter Wert, neuer Wert) geführt wird.
Schutz vor unbeabsichtigter Änderung	Für jeden Anwendungsfall ist parametrierbar, welche Daten änderbar sind. Dadurch wird verhindert, dass Daten ohne Bezug zum Anwendungsfall geändert werden. In File-Schnittstelle kann definiert werden, ob Files mehrmals eingelesen werden können. In REST-Schnittstellen kann definiert werden, ob eine identische Meldung, mehrfach verarbeitet wird
Schutz von Testumgebungen	Auf Testumgebungen können Emails-umgeleitet werden oder der Versand kann deaktiviert werden. PDF-Dokumente, die auf nicht produktiven Umgebungen aufbereitet werden, werden mit einem Wasserzeichen versehen
Schutz vor Dateninkonsistenz	Datenmanipulationen werden über das Persistenz-Framework innerhalb von Datenbank-Transaktionen durchgeführt.
Entkoppelung von Drittsystemen	Anbindungen an Drittsysteme werden wo möglich asynchron realisiert. Dadurch ist die Anwendung auch verfügbar, wenn ein angebundenes System nicht verfügbar ist.
Berücksichtigung OWASP-Top10	Bei der Implementierunge werden die OWASP-Top10 berücksichtigt.

Technologieauswahl

Backend-Anwendung:

Kern der Anwendung ist eine ASP.NET Core Anwendung, die eine REST-API bereitstellt. Es wird darauf geachtet, dass jeweils die aktuelle .NET Long Term Support (LTS) Version verwendet wird. Aktuell ist das .NET8.

Für das O/R-Mapping wird das Persistenz-Framework NHibernate eingesetzt. Es stellt sicher, dass verschiedene Datenbanken unterstützt werden können.

Die Suche basiert auf Lucene.NET, einem .NET-Library für performante Volltext-Suche.

Für das Logging wird das Logging-Library Serilog eingesetzt.

Die eingesetzte Basis-Technologie ist plattformunabhängig. Einige Module (z.B. Document-Templates, PDF-Bearbeitung, QR-Code-Detection) setzen jedoch Libraries ein, die Windows als Betriebsplattform voraussetzen. Aktuell wird daher ein Betrieb auf einem IIS in einer Windows-Umgebung empfohlen.

Längerfristig soll das Backend-API containerisiert auf Linux oder auf einem IIS unter Windows betrieben werden

Frontend-Anwendung:

Die Frontend-Anwendung ist als ASP.NET Core Anwendung umgesetzt. Die Singlepage Anwendung ist mit dem JavaScript Framework ExtJS von Sencha umgesetzt. Die Integration in die .NET Welt wird mit Ext.Direct sichergestellt.

Die Frontend-Anwendung lässt sich mit den gängigen Web-Browsern (z.B. Internet Explorer, Edge, Chrome, Firefox, Safari) ohne client-seitige Installation bedienen (Plugin-free). Das Frontend ist für die Verwendung mit Desktop-Geräten (PC, Notebook) vorgesehen.

Die eingesetzte Technologie ist plattformunabhängig. Die Frontendanwendung kann containerisiert auf Linux oder auf einem IIS unter Windows betrieben werden.

Datenbank:

Die Daten werden als relationale Daten in einer Microsoft SQL-Server Datenbank persistent gehalten. Alternativ wird das DBMS Oracle weiterhin unterstützt, um bestehende Installationen zu berücksichtigen.

Authentifizierung und Autorisierung:

elego nutzt die Autorisierungs- und Authentifizierungsmechanismen von OpenID Connect (OIDC). Als Identity Provider kann unser Eis Identity Provider oder ein anderer OIDC-fähiger IDP verwendet werden. Seit elego 51 ist auch eine direkte Anbindung an Azure Entra ID möglich.

Zur Umsetzung von OpenID Connect und OAuth 2.0 setzen wir auf das Duende Framework.