Architectuur Uniconta
Uniconta is een 3-lagen architectuur.
De client heeft slechts één verbinding met de Uniconta applicatieserver (UAS) en UAS is de enige verbinding met de SQL.
UAS laadt wat "toestand" van SQL en deze blijft in UAS en wordt vervolgens naar SQL geschreven tijdens updates. Maar bij lezen wordt de aanroep rechtstreeks vanuit UAS verzorgd.
Uniconta heeft slechts één SQL-database en alle gegevens worden opgeslagen in dezelfde SQL. Alle relaties in SQL zijn via RowId, niet via "sleutels".
Dit betekent dat een debiteur een unieke RowId heeft in de SQL en dat alle boekingen naar die debiteur verwijzen naar de RowId van die debiteur.
De debiteur zegt van welk bedrijf het is, maar de boeking zegt niet van welk bedrijf het is. Het is maar van één debiteur.
En zo is het met alle affiliaties. Ze behoren tot een master via een unieke SQL RowId.
Communicatie tussen client en server:
Uniconta gebruikt Uniconta.WindowsAPI
Uniconta.WindowsAPI is gebaseerd op standaard .NET en heeft encryptie.
Onze server heeft een "X509Certificate2" gegenereerd op onze server.
Het is een certificaat met een openbare sleutel en een privésleutel.
Het eerste wat de API doet bij het opstarten is de server aanroepen en om de publieke sleutel vragen. We versturen deze volledig onversleuteld. Het is per definitie openbaar.
Op deze manier worden pakketten die van de client naar de server worden gestuurd versleuteld via deze publieke sleutel. De enige die dit pakket kan ontsleutelen is onze server, omdat deze de privésleutel heeft die nodig is om het pakket te ontsleutelen.
Wanneer de client inlogt, zal hij in het pakket de gebruikersnaam, het wachtwoord, een willekeurig gegenereerde 32-bits lokale coderingssleutel (K1) en een 64-bits inlogidentificatiesleutel (K2) opnemen.
Wanneer de server het pakket ontvangt, wordt het gedecodeerd via zijn privésleutel en dan wordt de aanmeldingsoproep eruit gehaald.
Controleer vervolgens of de gebruikersnaam en het wachtwoord bestaan. Als deze bestaan, wordt er een sessie aangemaakt op de server. Deze sessie wordt geïdentificeerd door een automatisch gegenereerde GUID.
De sessie krijgt de 2 "codes" van de client K1 en K2 toegewezen. De sessie krijgt ook een volgnummer 1 toegewezen.
Wanneer de server het pakket terugstuurt naar de client, bevat het pakket de GUID en K2 en is het versleuteld met de K1-sleutel.
Wanneer de client het aanmeldpakket ontvangt, ontcijfert hij eerst met de K1 sleutel die hij zelf heeft gegenereerd en de client controleert dan of hij K2 terugkrijgt.
Het zal de GUID opslaan om te gebruiken voor toekomstige oproepen.
Nu is de client verbonden.
Het volgende pakket naar de server bevat GUID en volgnummer 2, en het wordt versleuteld met de publieke sleutel,
De server decodeert met de privésleutel. De server vindt de sessie via GUID. De server kijkt of sequentie nummer 2 al eerder is ontvangen. Als dat niet het geval is, wordt de oproep geregistreerd als sequentie nummer 2 die is ontvangen. Nu wordt de oproep verwerkt en op het retourpakket wordt het versleuteld met de K1-sleutel.
Als iemand anders het aanmeldingspakket onderschept dat naar de server wordt gestuurd en een Replay uitvoert, zal de server het pakket weigeren omdat K2 al bestaat, dus niemand met dezelfde K2 kan inloggen.
Als iemand anders de andere pakketten die naar de server zijn gestuurd wil onderscheppen en een Replay wil doen, zal de server het pakket weigeren omdat het volgnummer al is verwerkt.
Als iemand anders de andere pakketten die ACHTER de server worden verzonden wil onderscheppen, zal hij de K1 sleutel niet kennen en het pakket niet kunnen ontsleutelen.
Elke gebruiker heeft zijn eigen K1-sleutel gegenereerd en daarom worden alle retourpakketten anders versleuteld.
Een pakket dat is versleuteld naar de server met een openbare sleutel van het type "X509Certificate2" is vrijwel onmogelijk te ontsleutelen.
Het is het moeilijkst te ontcijferen. Alleen de persoon met de privésleutel kan het ontcijferen. Deze privésleutel verlaat de server nooit.
Alle pakketten die teruggestuurd worden van de server zullen niets bevatten over welke aanroep er gedaan is. Het zal alleen het resultaat bevatten. Dus een pakket kan simpelweg "ok" bevatten. Of "100" of leeg. Er is geen manier om aan het retourpakket te zien waar het van terugkomt.
We hebben 113 verschillende aanroepen, die allemaal binaire gegevens retourneren en geen gegevens over wat het pakket bevat. Dus zelfs als je onze api kunt compileren en erachter kunt komen hoe je het pakket uitpakt, weet je nog steeds niet welk pakket het is. En dat is pas nadat je erin geslaagd bent om het pakket te ontsleutelen met een sleutel die je ook niet kent.
Lees meer over waar wachtwoorden worden opgeslagen in Windows