mirror of
https://github.com/IT4Change/gradido.git
synced 2025-12-13 07:45:54 +00:00
Usecase erstelleCommunity inkl. Authentication fast fertig
This commit is contained in:
Claus-Peter Hübner
parent
9c211595c4
commit
b54ff72f11
@ -96,7 +96,7 @@ Da es also mehrere Communities geben wird, benötigt jede Community ihren eigene
|
||||
|
||||
Für die Verwaltung von Community-Mitgliedern werden entsprechende Verwaltungsprozesse wie Registrierung, Login mit Autentifizierung, eine Benutzerverwaltung für neue, bestehende und ausscheidende Mitgleider benötigt. Die Benutzerverwaltung stellt zusätzlich die Anforderung, dass ein Community-Mitglied eindeutig identifizierbar ist und das Community übergreifend. Das bedeutet es kann eine Person immer nur einmal existieren und darf auch niemals in mehreren Communities gleichzeitig Mitglied sein. Denn es muss sichergestellt werden, dass eine Person sich keine unerlaubte Vorteile durch zum Beispiel mehrfache Geldschöpfung in mehreren Communities verschafft.
|
||||
|
||||
Die Details der Mitgliederverwaltung werden beschrieben im Dokument [BenutzerVerwaltung](.\BenutzerVerwaltung.md).
|
||||
Die Details der Mitgliederverwaltung werden beschrieben im Dokument [BenutzerVerwaltung](./BenutzerVerwaltung.md).
|
||||
|
||||
### Community-Netzwerk
|
||||
|
||||
@ -183,7 +183,7 @@ Für die Dreifach-Geldschöpfung verwaltet die Community drei Arten von Konten:
|
||||
|
||||
Für jedes Mitglied der Community wird also ein eigenes AktiveGrundeinkommen-Konto verwaltet, auf das ein Drittel der monatlichen Geldschöpfung unter Einhaltung der AGE-Regeln fließt. Das Gemeinwohlkonto und das AUF-Konto existieren pro Community einmal und auf jedes der beiden Konten fließen monatlich die beiden anderen Drittel der Geldschöpfung.
|
||||
|
||||
Somit muss also eine Community für jede Kontoart die entsprechenden Kontoverwaltungsprozesse anbieten. Einmal in Verbindung pro Mitglied für das AGE-Konto und dann jeweils eine Verwaltung für das Gemeinwohlkonto und eine Verwaltung für das AUF-Konto. Die Berechtigungen für die Zugriffe auf die drei Kontoarten müssen ebenfalls in der Community gepflegt und kontrolliert werden. Das bedeutet die Community muss ihren Mitgliedern auf ihre eigenen AGE-Konten Zugriffsrechte erteilen und diese auch kontrollieren, so dass keine unerlaubten Zugriffe stattfinden können. Dann müssen in der Community bestimmte Mitglieder Sonderberechtigungen erhalten, um die Verwaltung des Gemeinwohlkontos und des AUF-Kontos durchführen zu können. Die Verwaltung der Berechtigungen ist wiederum alleine dem Community-Administrator erlaubt. Die Details der Kontenverwaltung ist im Dokument [KontenVerwaltung](.\KontenVerwaltung.md) beschrieben.
|
||||
Somit muss also eine Community für jede Kontoart die entsprechenden Kontoverwaltungsprozesse anbieten. Einmal in Verbindung pro Mitglied für das AGE-Konto und dann jeweils eine Verwaltung für das Gemeinwohlkonto und eine Verwaltung für das AUF-Konto. Die Berechtigungen für die Zugriffe auf die drei Kontoarten müssen ebenfalls in der Community gepflegt und kontrolliert werden. Das bedeutet die Community muss ihren Mitgliedern auf ihre eigenen AGE-Konten Zugriffsrechte erteilen und diese auch kontrollieren, so dass keine unerlaubten Zugriffe stattfinden können. Dann müssen in der Community bestimmte Mitglieder Sonderberechtigungen erhalten, um die Verwaltung des Gemeinwohlkontos und des AUF-Kontos durchführen zu können. Die Verwaltung der Berechtigungen ist wiederum alleine dem Community-Administrator erlaubt. Die Details der Kontenverwaltung ist im Dokument [KontenVerwaltung](./KontenVerwaltung.md) beschrieben.
|
||||
|
||||
### Tätigkeitsverwaltung
|
||||
|
||||
@ -242,11 +242,11 @@ Dieses Listenattribut beinhaltet Benutzer-Elemente, die erfolgreich als Mitglied
|
||||
|
||||
#### Gemeinwohlkonto
|
||||
|
||||
Das Attribut *Gemeinwohlkonto* dient als ein Konto-Element, das den Kontotyp Gemeinwohlkonto repräsentiert. Alle Kontobewegungen, wie Geldschöpfung, Geldtransfers, etc., die das Gemeinwohl dieser Community betreffen, werden über dieses Attribut abgewickelt. Details zu Kontobewegungen werden im Dokument [KontenVerwaltung](KontenVerwaltung.md) beschrieben und die Regeln und Vorgänge der Geldschöpfung sind im Dokument [RegelnDerGeldschoepfung](RegelnDerGeldschoepfung.md) zu finden. Auf dieses Attribut haben nur Mitglieder mit entsprechenden Zugriffsrechten die Erlaubnis und Möglichkeiten darauf Einsicht zu nehmen und Prozesse auszulösen.
|
||||
Das Attribut *Gemeinwohlkonto* dient als ein Konto-Element, das den Kontotyp Gemeinwohlkonto repräsentiert. Alle Kontobewegungen, wie Geldschöpfung, Geldtransfers, etc., die das Gemeinwohl dieser Community betreffen, werden über dieses Attribut abgewickelt. Details zu Kontobewegungen werden im Dokument [KontenVerwaltung](./KontenVerwaltung.md) beschrieben und die Regeln und Vorgänge der Geldschöpfung sind im Dokument [RegelnDerGeldschoepfung](./RegelnDerGeldschoepfung.md) zu finden. Auf dieses Attribut haben nur Mitglieder mit entsprechenden Zugriffsrechten die Erlaubnis und Möglichkeiten darauf Einsicht zu nehmen und Prozesse auszulösen.
|
||||
|
||||
#### Ausgleichs- und Umweltkonto AUF-Konto
|
||||
|
||||
Das Attribut *Ausgleichs- und Umweltkonto* dient als ein Konto-Element, das den Kontotyp AUF-Konto repräsentiert. Alle Kontobewegungen, wie Geldschöpfung, Geldtransfers, etc., die das AUF-Konto dieser Community betreffen, werden über dieses Attribut abgewickelt. Details zu Kontobewegungen werden im Dokument [KontenVerwaltung](KontenVerwaltung.md) beschrieben und die Regeln und Vorgänge der Geldschöpfung sind im Dokument [RegelnDerGeldschoepfung](RegelnDerGeldschoepfung.md) zu finden. Auf dieses Attribut haben nur Mitglieder mit entsprechenden Zugriffsrechten die Erlaubnis und Möglichkeiten darauf Einsicht zu nehmen und Prozesse auszulösen.
|
||||
Das Attribut *Ausgleichs- und Umweltkonto* dient als ein Konto-Element, das den Kontotyp AUF-Konto repräsentiert. Alle Kontobewegungen, wie Geldschöpfung, Geldtransfers, etc., die das AUF-Konto dieser Community betreffen, werden über dieses Attribut abgewickelt. Details zu Kontobewegungen werden im Dokument [KontenVerwaltung](./KontenVerwaltung.md) beschrieben und die Regeln und Vorgänge der Geldschöpfung sind im Dokument [RegelnDerGeldschoepfung](./RegelnDerGeldschoepfung.md) zu finden. Auf dieses Attribut haben nur Mitglieder mit entsprechenden Zugriffsrechten die Erlaubnis und Möglichkeiten darauf Einsicht zu nehmen und Prozesse auszulösen.
|
||||
|
||||
#### Verteilungsschlüssel der Dreifachen-Schöpfung
|
||||
|
||||
@ -299,26 +299,31 @@ Der oben grafisch dargestellte Ablauf wird in drei grobe Teile untergliedert:
|
||||
* Sollte es keine solche Einträge geben, dann werden die eigenen Daten *Community-Ke*y und *URL* in eine *replyNewCommunity*-Message gepackt, der *MessageState = OK* gesetzt und direkt in den Public-Channel zurückgesendet. Danach wird wieder in den "Lausch-Modus" am Public-Channel gewechselt.
|
||||
3. und die *"Community-Communication"* als Hintergrundprozess. Dieser liest zuerst die eigenen Community-Daten und geht dann per Direkt-Verbindung über die URL mit der neuen Community in Dialog, um sich zuerst gegenseitig zu authentifizieren und um dann die Community spezifischen Daten untereinander auszutauschen. Der logische Ablauf dieser Kommunikation soll wie folgt dargestellt ablaufen:
|
||||
|
||||
|
||||
|
||||
|
||||
Die genaue Beschreibung der dazu verwendeten APIs beider Communities erfolgt in der technischen Konzeption [CommunityCommunication](../TechnicalRequirements/CommunityCommunication.md). Wie der obigen Grafik zu entnehmen ist, erfolgt bei einer neuen Community eine einmalig zu durchlaufende Aufruf-Kette zur Authentifizierung (1. Sequenz), deren Ergebnisse in den beteiligten Communities gespeichert bleiben. Der danach folgende Request (2. Sequenz) wird vor jeder neu initiierten Kommunikation zwischen zwei Communities notwendig, um ein zeitlich gültiges Authentifizierungs-Token für die nachfolgenden fachlichen Requeste (3. Sequenz) zu erhalten.
|
||||
|
||||
Die erste fachliche Kommunikation zwischen einer neu erstellten und einer schon existierenden Community ist die Annäherung der beiden Communities in dem sie sich gegenseitig mit dem Request "*familiarizeCommunity*" ihre eigenen Daten in Form eines *CommunityTO*-TransferObjektes austauschen. Im zweiten Schritt erfragen sie sich gegenseitig, wie sie zukünftig miteinander Handel treiben wollen. Die Details über diesen *request/confirm-TradingLevel*-Prozess sind im technischen Dokument [CommunityCommunication](../TechnicalRequirements/CommunityCommunication.md " ") beschrieben.
|
||||
|
||||
Die genaue Beschreibung der dazu verwendeten APIs beider Communities erfolgt in der technischen Konzeption [CommunityCommunication](../TechnicalRequirements/CommunityCommunication.md).
|
||||
|
||||
#### Ende Status
|
||||
|
||||
1. Community-Infrastruktur ist installiert und aktiv
|
||||
2. neue Community ist erzeugt und Daten in der Community-DB gespeichert
|
||||
3. der Hintergrundprozess "Community-Vernetzung" ist am Laufen
|
||||
3. der Hintergrundprozess *Federatio*n ist am Laufen
|
||||
* die initiale "newCommunity-Msg" mit den eigenen Community-Daten ist in den Public-Channel versendet
|
||||
* ein Listener lauscht am Public-Channel auf Antworten (*replyNewCommunity*-Msg) der schon existenten Communities
|
||||
* ein Listener lauscht am Public-Channel auf initiale "*newCommunity*-Msg" anderer neuer Communities
|
||||
4. mit dem ersten Empfangen einer *replyNewCommunity*-Msg einer anderen Community, wird der *Community-Communication* Prozess gestartet, der mit jedem Empfang von neuen Community-Daten eine P2P-Verbindung zu dieser Community aufbaut, um direkt detaillierte Daten auszutauschen
|
||||
5. die vordefinierte Tätigkeitsliste ist geladen
|
||||
6. die vordefinierten Berechtigungen sind aktiv
|
||||
7. optional sind schon Mitglieder erfasst und in der Datenbank gespeichert
|
||||
4. mit dem ersten Empfangen einer *replyNewCommunity*-Msg einer anderen Community, wird der *Community-Communication* Prozess gestartet und ist am Laufen.
|
||||
5. mit jedem Empfang einer *replyNewCommunity*-Msg haben sich die involvierten Communities direkt miteinander verbunden, sich gegenseitig authentifiziert (Austausch der public-Keys) und weitere Daten ausgetauscht
|
||||
6. die vordefinierte Tätigkeitsliste ist geladen
|
||||
7. die vordefinierten Berechtigungen sind aktiv
|
||||
8. optional sind schon Mitglieder erfasst und in der Datenbank gespeichert
|
||||
|
||||
#### Fehlerfälle
|
||||
|
||||
|
||||
|
||||
### Community bearbeiten
|
||||
|
||||
*Allgemeine fachliche Beschreibung des Anwendungsfalles.*
|
||||
|
||||
@ -4,15 +4,21 @@
|
||||
<root>
|
||||
<mxCell id="0"/>
|
||||
<mxCell id="1" parent="0"/>
|
||||
<mxCell id="30" value="" style="endArrow=none;html=1;fontSize=20;" parent="1" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="260" y="1480" as="sourcePoint"/>
|
||||
<mxPoint x="260" y="540" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="64" value="" style="endArrow=none;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;" parent="1" target="63" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="1299.5" y="1621" as="sourcePoint"/>
|
||||
<mxPoint x="1300" y="1480" as="sourcePoint"/>
|
||||
<mxPoint x="1299.5" y="200" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="62" value="" style="endArrow=none;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;" parent="1" target="61" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="1160" y="1621" as="sourcePoint"/>
|
||||
<mxPoint x="1160" y="1190" as="sourcePoint"/>
|
||||
<mxPoint x="890" y="380" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
@ -82,26 +88,17 @@
|
||||
<mxPoint x="970" y="1363" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="21" value="request with TradingLevelTO-InputData" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=12;" parent="20" vertex="1" connectable="0">
|
||||
<mxCell id="21" value="request with JWT-Token and TradingLevelTO-InputData" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=12;" parent="20" vertex="1" connectable="0">
|
||||
<mxGeometry x="0.1296" relative="1" as="geometry">
|
||||
<mxPoint as="offset"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="22" value="store<br>TradingLevel" style="rounded=0;whiteSpace=wrap;html=1;fontSize=12;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="1423" width="100" height="30" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="23" value="create open admin request for<br>TradingLevel" style="rounded=0;whiteSpace=wrap;html=1;fontSize=12;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="1463" width="100" height="50" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="24" value="create open admin request for<br>TradingLevel" style="rounded=0;whiteSpace=wrap;html=1;fontSize=12;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="1523" width="100" height="50" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="8" value="Service:<br><b>authenticate<br>Community</b>" style="rounded=0;whiteSpace=wrap;html=1;fontSize=12;" parent="1" vertex="1">
|
||||
<mxGeometry x="970" y="280" width="100" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="26" value="" style="endArrow=none;html=1;fontSize=20;entryX=0.5;entryY=1;entryDx=0;entryDy=0;startArrow=none;" parent="1" target="8" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="1020" y="1620" as="sourcePoint"/>
|
||||
<mxPoint x="1020" y="1190" as="sourcePoint"/>
|
||||
<mxPoint x="1019.5" y="220" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
@ -111,12 +108,6 @@
|
||||
<mxCell id="28" value="generate and keep<br>one-time code together with given encrypted community key&nbsp;" style="rounded=0;whiteSpace=wrap;html=1;fontSize=12;" parent="1" vertex="1">
|
||||
<mxGeometry x="970" y="380" width="100" height="90" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="30" value="" style="endArrow=none;html=1;fontSize=20;" parent="1" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="260" y="1622" as="sourcePoint"/>
|
||||
<mxPoint x="260" y="540" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="31" value="" style="endArrow=classic;html=1;fontSize=12;exitX=0;exitY=1;exitDx=0;exitDy=0;entryX=1;entryY=0;entryDx=0;entryDy=0;" parent="1" source="28" target="38" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="970" y="521" as="sourcePoint"/>
|
||||
@ -154,8 +145,8 @@
|
||||
<mxCell id="13" value="initialize CommunityTO" style="rounded=0;whiteSpace=wrap;html=1;fontSize=12;" parent="1" vertex="1">
|
||||
<mxGeometry x="210" y="1203" width="100" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="15" value="define and store<br>TradingLevel" style="rounded=0;whiteSpace=wrap;html=1;fontSize=12;" parent="1" vertex="1">
|
||||
<mxGeometry x="210" y="1333" width="100" height="30" as="geometry"/>
|
||||
<mxCell id="15" value="define and offer<br>own TradingLevel Idea" style="rounded=0;whiteSpace=wrap;html=1;fontSize=12;" parent="1" vertex="1">
|
||||
<mxGeometry x="210" y="1320" width="100" height="43" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="39" value="" style="endArrow=classic;html=1;fontSize=12;exitX=0;exitY=1;exitDx=0;exitDy=0;entryX=1;entryY=0;entryDx=0;entryDy=0;" parent="1" source="47" target="46" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
@ -262,11 +253,11 @@
|
||||
<mxPoint x="1370" y="210.00000000000045" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="66" value="<font style="font-size: 16px">singular processing after community creation</font>" style="text;html=1;strokeColor=none;fillColor=none;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="210" width="140" height="100" as="geometry"/>
|
||||
<mxCell id="66" value="<font style="font-size: 16px">1. Sequence:<br>singular processing after community creation</font>" style="text;html=1;strokeColor=none;fillColor=none;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="210" width="140" height="120" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="67" value="<font style="font-size: 16px">recurrent processing to open community communication session</font>" style="text;html=1;strokeColor=none;fillColor=none;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="810" width="140" height="120" as="geometry"/>
|
||||
<mxCell id="67" value="<font style="font-size: 16px">2. Sequence:<br>recurrent processing to open community communication session</font>" style="text;html=1;strokeColor=none;fillColor=none;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="810" width="140" height="150" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="68" value="" style="endArrow=none;dashed=1;html=1;strokeWidth=2;" parent="1" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
@ -274,8 +265,20 @@
|
||||
<mxPoint x="1370" y="1190" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="69" value="<font style="font-size: 16px">community communication session</font>" style="text;html=1;strokeColor=none;fillColor=none;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="1190" width="140" height="80" as="geometry"/>
|
||||
<mxCell id="69" value="<font style="font-size: 16px">3. Sequence:<br>community communication session</font>" style="text;html=1;strokeColor=none;fillColor=none;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="1190" width="140" height="100" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="70" value="" style="endArrow=none;dashed=1;html=1;dashPattern=1 3;strokeWidth=4;" edge="1" parent="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="261" y="1580" as="sourcePoint"/>
|
||||
<mxPoint x="261" y="1480" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="71" value="" style="endArrow=none;dashed=1;html=1;dashPattern=1 3;strokeWidth=4;" edge="1" parent="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="1299.5" y="1580" as="sourcePoint"/>
|
||||
<mxPoint x="1299.5" y="1480" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 202 KiB After Width: | Height: | Size: 193 KiB |
@ -4,7 +4,7 @@ This document contains the detailed descriptions of the public API of a communit
|
||||
|
||||
## Authentication/Autorization of new Community
|
||||
|
||||
Each public API of a community has to be authenticated and autorized before.
|
||||
Each public API of a community has to be authenticated and autorized before.
|
||||
|
||||
### Variant A:
|
||||
|
||||
@ -18,13 +18,17 @@ The authentication of communities base on the community-attributes *key* and *UR
|
||||
|
||||
A similar solution of authentication to variant A but **without autorization** can be done by using private and public key encryption. The *community creation* process will create a private and public key and store them internally. As the third step of the federation the *community communication* background process of the new *community-A* will be startet and a sequence of service invocations will exchange the necessary security data:
|
||||
|
||||
|
||||
|
||||
**1.Sequence**
|
||||
|
||||
1. the new *community-A* encrypt the community key of the existing *community-B* with its own privat key. Then it invokes the service *authenticateCommunity* at *community-B* by sending the own community key, the encrypted community key of *community-B* and a redirect URI back to *community-A* as input data. The *community-B* will search the given community key of *community-A* in the internally stored list of communities, which are a result of the previous *federation process* collected over a different medium.
|
||||
2. If in *community-B* the given community key of *community-A* is found, a generated one-time code is kept together with the given encrypted community key, till an invocation of the service verifyOneTimeCode with this one-time-code. The one-time-code is passed back to the given Redirect URI of the *community-A*.
|
||||
2. If in *community-B* the given community key of *community-A* is found, a generated one-time code is stored together with the given encrypted community key in the community-entry of community-A, till an invocation of the service *verifyOneTimeCode* with this one-time-code. The one-time-code is passed back to the given Redirect URI of the *community-A*.
|
||||
3. *Community-A* will send with the next invocation to *community-B* the received one-time code and the own public key by requesting the service *verifyOneTimeCode* at *community-B*.
|
||||
4. *Community-B* will verify the given one-time-code and if valid, decrypt the previous received and encrypted community key from step 1 of the invocation-chain by using the given public key from *community-A*. If the decrypted community-key is equals the own community key, the public key of *community-A* is stored in the entry of *community-A* of the internal community list. As response of the *verifyOneTimeCode* the *community-B* will send back his own public key to *community-A*.
|
||||
5. *Community-A* will store the received public key of *community-B* in the corresponding entry of the internal community-list.
|
||||
|
||||
The result of this invocation chain is the public key exchange of the involved communities, which is the foundation to authenticate a future cross community communication.
|
||||
The result of this invocation chain is the public key exchange of the involved communities, which is the foundation to authenticate a future cross community communication - see Sequnce 2 and 3.
|
||||
|
||||
To reach in Variant B nearly the same security level as in Variant A each community has to integrate several components to process this invocation chain like Variant A does.
|
||||
|
||||
@ -36,12 +40,12 @@ The third Variant exchange the all necessary data directly without the step in b
|
||||
2. If in *community-B* the given community key of *community-A* is found and if the decryption of the given encrypted community key with the given public key is equals the own community key, the public key of *community-A* is stored in the entry of *community-A* of the internal community list. As response of the *authenticateCommunity* the *community-B* will send back his own public key to *community-A*.
|
||||
3. *Community-A* will store the received public key of *community-B* in the corresponding entry of the internal community-list.
|
||||
|
||||
Variant C is quite similar to Variant B, but to exchange all security relevant data in a single request-response-roundtrip bears more security risks.
|
||||
Variant C is quite similar to Variant B, but to exchange all security relevant data in a single request-response-roundtrip bears more security risks and should be avoided.
|
||||
|
||||
|
||||
## Service: "Authenticate Community"
|
||||
|
||||
This service must be invoked at first to exchange the security relevant data before further cross community communication can be done.
|
||||
This service must be invoked at first - see Variant B above - to exchange the security relevant data before further cross community communication can be done.
|
||||
|
||||
The third step of the *federation process* starts the background process for community communication. As result of the previous federation steps the new community has received from at least one existing community the URL and the community key.
|
||||
|
||||
@ -56,26 +60,27 @@ POST https://<New_Community_URL>/authenticateCommunity
|
||||
```
|
||||
{
|
||||
"community-key-A" : "the community-key of the new community-A"
|
||||
"community-key-B" : "the community-key of the existing community-B, which was replied during the federation, encrypted by the own private key"
|
||||
"community-key-B" : "the community-key of the community-B, replied during the federation, encrypted by the private key of community-A"
|
||||
"redirectionURI" : "the URI for the redirection callback"
|
||||
}
|
||||
```
|
||||
|
||||
### Output-Data:
|
||||
|
||||
* none
|
||||
* redirection URI: "one-time-code" : "one-time usable code as input for the service verifyOneTimeCode"
|
||||
* redirection URI: "one-time-code" : "one-time usable code with short expiration time as input for the service *verifyOneTimeCode*"
|
||||
|
||||
### Exceptions:
|
||||
|
||||
*MissingParameterException* if any of the parameter attributes is not initialized.
|
||||
|
||||
*UnknownCommunityException* if the community search with the value of parameter "community-key-A" could not find a matching community entry with this key.
|
||||
|
||||
|
||||
|
||||
## Service: "Verify OneTimeCode"
|
||||
|
||||
This service must be invoked at first to exchange the security relevant data before further cross community communication can be done.
|
||||
|
||||
The third step of the *federation process* starts the background process for community communication. As result of the previous federation steps the new community has received from at least one existing community the URL and the community key.
|
||||
|
||||
To prepare the input-data for the invocation the own community key and the community key of the new community
|
||||
This service must be invoked directly after getting the *one-time code*, because this code has a very short expiration time. Together with the public key of *community-A* the one-time code is send as input data to *community-B*. The service verifies the given *one-time code* and if valid it decrypt with the given *public key* the previous receive *community-key-B* from the request *authenticateCommunity*. If this decrypted community-key is equals the own community-key the *public key* is stored in the community-entry of *community-A* of the internal community-list.
|
||||
|
||||
### Route:
|
||||
|
||||
@ -85,20 +90,32 @@ POST https://<New_Community_URL>/verifyOneTimeCode
|
||||
|
||||
```
|
||||
{
|
||||
"public-key" : "the public key of the new community (community-B)"
|
||||
"src-community-key" : "the community-key of the new community encrypted by the own private key"
|
||||
"dst-community-key" : "the community-key of the existing community, which replied during the federation encrypted by the own provate key"
|
||||
"one-time-code" : "one-time code with short expiration, received from community-B per redirect URI"
|
||||
"public-key" : "the public key of the new community (community-A)"
|
||||
}
|
||||
```
|
||||
|
||||
### Output-Data:
|
||||
|
||||
```
|
||||
{
|
||||
"public-key" : "the public key of community-B"
|
||||
}
|
||||
```
|
||||
|
||||
### Exceptions:
|
||||
|
||||
*MissingParameterException* if one of the parameter attributes is not initialized.
|
||||
|
||||
*InvalidOneTimeCodeException* if the one-time-code is expired, invalid or unknown.
|
||||
|
||||
*SecurityException* if the decryption result with the given parameter *public-key* and previous receive *community-key-B* from the request *authenticateCommunity* doesn't match with the own community-key.
|
||||
|
||||
|
||||
## Service: "open Communication"
|
||||
|
||||
**ongoing...**
|
||||
|
||||
|
||||
### Route:
|
||||
|
||||
@ -117,6 +134,7 @@ POST https://<New_Community_URL>/openCommunication
|
||||
### Exceptions:
|
||||
|
||||
|
||||
|
||||
## Service: "Familiarize communities"
|
||||
|
||||
This request is used to exchange data between an existing and a new community. It will be invoked by the existing community, which received a valid *newCommunity*-Message from a new community during the federation process.
|
||||
@ -175,10 +193,9 @@ In case the transferred community-key from the service-consumer will not match t
|
||||
|
||||
In case the transferred data can't be stored on service-provider the exception *WriteAccessException* will be thrown.
|
||||
|
||||
|
||||
## Service: "request TradingLevel"
|
||||
|
||||
With this service a community can ask for a trading level with another community. The *community-A* invokes this service at *community-B* to offer the own vision of trading with *community-B* by sending a TradingLevelTO with all the initialized Flags for future data exchanges. *Community-B* will store these data in the entry of *community-A* of its internal community list and mark it as an *open admin request* for trading level. Such an *open admin request* will inform the administrator of *community-B*, because administrative interactions and decisions are necessary.
|
||||
With this service a community can ask for a trading level with another community. The *community-A* invokes this service at *community-B* to offer the own vision of trading with *community-B* by sending a TradingLevelTO with all the initialized Flags for future data exchanges. *Community-B* will store these data in the entry of *community-A* of its internal community list and mark it as an *open admin request* for trading level. Such an *open admin request* will inform the administrator of *community-B*, because administrative interactions and decisions are necessary.
|
||||
|
||||
After the administrator of *community-B* has cleared all community internal aspects for the requested trading level with *community-A,* he will update the stored trading level flags for *community-A* and send this data by calling the service "confirm trading Level" of *community-A*.
|
||||
|
||||
@ -214,8 +231,6 @@ POST https://<Community-B_URL>/requestTradingLevel/`<security-accesstoken>`
|
||||
|
||||
### Exceptions:
|
||||
|
||||
|
||||
|
||||
## Service: "confirm TradingLevel"
|
||||
|
||||
With this service a community sends his trading level confirmation to a previous *requestTradingLevel* invocation of another community. The *community-B* invokes this service at *community-A* to confirm the previous received and optionally updated vision of trading level data with *community-A*. This service sends the TradingLevelTO with the confirmed flags for future data exchanges between *community-A* and *community-B*. *Community-A* will store this data in the entry of *community-B* of its internal community list and mark it as a *confirmed admin request* for trading level. The update of a *admin request* to state *confirmed* will inform the administrator of *community-A* to trigger administrative interactions and decisions.
|
||||
@ -254,7 +269,6 @@ POST https://<Community-B_URL>/requestTradingLevel/`<security-accesstoken>`
|
||||
|
||||
### Exceptions:
|
||||
|
||||
|
||||
## Service: "Member of Community"
|
||||
|
||||
Before user A can start any cross-community interactions with user B, this service api can be used to check if user B is a valid member of the other community.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user