Uniconta-Architektur
Uniconta hat eine dreischichtige Architektur.
Der Client hat nur eine Verbindung zum Uniconta-Anwendungsserver (UAS) und UAS ist die einzige Verbindung zum SQL-Server.
UAS lädt einen partiellen „Zustand“ aus der SQL-Datenbank, der im UAS verbleibt und bei Aktualisierungen wieder in die SQL-Datenbank zurückgeschrieben wird. Beim Lesen wird der Anruf jedoch direkt vom UAS bedient.
Uniconta hat einen SQL-Server und alle Daten befinden sich in derselben SQL-Datenbank. Alle Beziehungen zur SQL-Datenbank erfolgen über RowIds, nicht über „Schlüssel“.
Beispiel: ein Kunde hat eine eindeutige RowId für die gesamte SQL-Datenbank. Alle Transaktionen mit diesem Kunde beziehen sich auf diese RowId. Für den Anwender ist die eindeutige Kennung die Kundennummer. Diese ist aber unabhängig von der RowId. Deshalb ist es auch einfach die Kundennummer zu ändern. Durch die interne Verknüpfung ist die Änderung für alle Transaktionen sofort wirksam.
Systemintern ist die eindeutige Kennung des Kunden die UnternehmensID plus der RowId.
Dies gilt für alle Arten von Stammdaten und deren verbundene Transaktionen.
Kommunikation zwischen dem Client und dem Server
Uniconta verwendet Uniconta.WindowsAPI
Uniconta.WindowsAPI baut auf dem standardisierten .NET-Framework auf und ist verschlüsselt.
Der Unicontar Server hat ein „X509Certificate2“ generiert.
Dies ist ein Zertifikat mit einem öffentlichen und einem privaten Schlüssel.
Beim Start ruft die API den Server auf und fordert den öffentlichen Schlüssel an. Diese wird dann komplett unverschlüsselt versendet (ist also per Definition öffentlich).
Dabei werden mit diesem öffentlichen Schlüssel verschlüsselte Pakete vom Client zum Server gesendet. Nur unser Server kann das Paket entschlüsseln, da er über den erforderlichen privaten Schlüssel verfügt.
Wenn der Client ein Login erstellt, enthält dieses einen Benutzernamen, ein Passwort, einen zufällig generierten lokalen 32-Bit-Verschlüsselungsschlüssel (K1) und einen 64-Bit-Login-Ident-Schlüssel (K2).
Wenn der Server das Anmeldepaket erhält, wird es mit seinem privaten Schlüssel entschlüsselt und der Anmeldename entpackt.
Es prüft dann, ob der Benutzername und das Passwort existieren. Wenn sie vorhanden sind, startet der Server die Sitzung. Diese Sitzung wird mit einer automatisch generierten GUID identifiziert.
Der Sitzung sind zwei „Codes“ für die Clients K1 und K2 zugeordnet. Der Sitzung wird außerdem die Sequenznummer 1 zugewiesen.
Wenn der Server das Paket an den Client zurückgibt, enthält es die GUID und den K2 und wird mit dem K1-Schlüssel verschlüsselt.
Wenn der Client das Anmeldepaket erhält, wird es mit dem von ihm generierten K1-Schlüssel entschlüsselt und der Client überprüft, ob er den K2 erhält.
Die GUID wird für zukünftige Aufrufe gespeichert.
Der Client ist jetzt verbunden.
Das folgende Paket an den Server enthält die GUID und die Sequenznummer 2, die mit dem öffentlichen Schlüssel verschlüsselt wird.
Der Server entschlüsselt es mit dem privaten Schlüssel. Der Server findet die Sitzung anhand der GUID. Der Server schaut nach, ob er Sequenznummer 2 schon einmal erhalten hat. Wenn dies nicht der Fall ist, dann registriert der Anruf, dass Sequenznummer 2 nun empfangen wurde. Der Anruf wird nun bearbeitet und der K1-Schlüssel auf dem Rückpaket verschlüsselt.
Wenn jemand anderes versucht, das an den Server gesendete Anmeldepaket zu verwenden und eine Wiedergabe durchzuführen, lehnt der Server das Paket ab, da der K2 bereits vorhanden ist. Das bedeutet, dass niemand mit demselben K2 Zugriff erhalten kann.
Wenn jemand anderes versucht, die anderen Pakete, die an den Server gesendet werden, zu verwenden und eine Wiedergabe durchzuführen, weist der Server das Paket zurück, da die Sequenznummer bereits verwendet wurde.
Wenn jemand anderes versucht, die anderen Pakete zu verwenden, die vom Server zurückgesendet werden, verfügt er nicht über den K1-Schlüssel und kann das Paket daher nicht entschlüsseln.
Alle Benutzer haben ihren eigenen K1-Schlüssel generiert, daher werden alle Rückpakete ohnehin unterschiedlich verschlüsselt.
Ein Paket, das mit einem öffentlichen Schlüssel „X509Certificate2“ verschlüsselt an den Server gesendet wird, ist praktisch nicht zu entschlüsseln.
Es ist einer der am schwierigsten zu entschlüsselnden Schlüssel. Nur die Person mit dem privaten Schlüssel kann diesen entschlüsseln. Dieser private Schlüssel verlässt niemals den Server.
Keines der vom Server zurückgegebenen Pakete enthält Informationen darüber, welcher Aufruf verwendet wurde. Sie enthalten nur das Ergebnis. Ein Paket kann also nur „ok“ oder „100“ enthalten oder leer sein. Es gibt keine Möglichkeit, das Rückpaket anzuzeigen.
Uniconta hat 113 verschiedene Aufrufe, die alle binäre Daten und keine Daten über den Inhalt des Pakets zurückgeben. Selbst wenn es jemandem gelingt, unsere API zu kompilieren und so herauszufinden, wie er das Paket anzeigen kann, weiß er immer noch nicht, um welches Paket es sich handelt. Das wäre nur möglich, nachdem es jemand geschafft hätte, das Paket mit einem Schlüssel zu entschlüsseln, auf den es aber keinen Zugriff gibt.