Anforderungen CyMaIS SaaS Anwendung

Anforderungen an die SaaS Anwendung

  • Die Anwendung soll in Docker laufen und deployed werden
  • Präferenz MariaDB als Datenbank

MVP I

Registrierung

  • Die Nutzerregistrierung soll aktiviert sein
  • Nutzer hat einen Nutzernamen (lediglich buchstaben, keine sonderzeichen, zahlen)
  • Email muss angeben werden
  • Passwort wird angegeben

Login

  • Eine Login Möglichkeit (Nutzername, Passwort) existiert

Profilseite

  • Eine Profilseite existiert
  • Passwort kann geändert werden
  • Nutzername ist unveränderlich

Admin

  • Übersichtsseite existiert
  • Nutzer müssen durch einen Administrator freigeschaltet werden

MVP II

Schnittstelle

Kontext

Im folgenden geht es darum, dass pro Anwendung CRUD Befehle auf die LDAP Datenbank und ggf. auf die Anwendungen ausgeführt werden können. Über die SaaS Anwendung, soll ein einheitliches Anwendungsübergreifendes Nutzermanagement erfolgen.

Schnittstellendateien

Eine Schnittstelle besteht aus folgenden dateien:

Datei Beschreibung
README.md Platz zur Dokumentation
meta.yml Enthält, die parameter, anzeige und rechtedefinitionen
create.py Script das einen Nutzer in der Applikation anlegt
read.py Script das Nutzerattribute aus einer Anwendung ausliest
update.py Script das einen Nutzer in der Applikation updated
create.py Script das einen Nutzer in der Applikation löscht

Beispiel


wordpress/
├── README.md
├── meta.yml
├── create.py
├── read.py
└── update.py

nextcloud/
├── README.md
├── meta.yml
├── create.py
├── read.py
└── update.py

mailu/
├── README.md
├── meta.yml
├── create.py
├── read.py
└── update.py

matrix/
├── README.md
├── meta.yml
├── create.py
├── read.py
└── update.py
meta.yml

Jede Schnittstelle soll über einen YAML file definiert werden (z.B. ein yaml file für nextcloud, wordpress, etc.) um zu gewährleisten, welche parameter abgefragt und angezeit werden sollen


username:
    field:
        type: string
        name: user_name    # Variablenwert der von den python scripten und zur forms generierung verendet wird
        label: User Name
        # More attributs to define the field, restrictions etc.
    permissions:
        create:                 # Administratoren und Moderatoren können Nutzer anlegen
            - administrators
            - moderators
        read:   all             # Alle können den Nutzernamen einer Anwendung auslesen
        update: none            # Nutzername ist unveränderlich
        delete: none            # Nutzername kann nicht gelöscht werden
    
storage_space:
    field:
        type: int
        label: Storage Space
        name: storage_space
    unit: Byte
    permission:
        create:                 # Administratoren und Moderatoren können Nutzer anlegen
            - administrators
            - moderators
        read:   user            # Nur der Nutzer selbst kann seinen Nutzernamen auslesen 
        update:                 # Speicherplatz kann nur von Administratoren und Moderatoren angepasst werden
            - administrator
            - moderators
        delete: none            # Löschen des wertes nicht möglich
        
# ... Weitere Attribute

Die Idee ist aus diesen werten die anzeige im Frontend rollenabhängig für

  • Administratoren
  • Moderatoren
  • User

zu generieren.

python scripte

Die felder die hier abgefragt werden sollen dann als json an python scripte übergeben welche die Manipulation an den LDAP einträgen und in den Einzelanwendungen vornehmen.

Beispiel

    python update.py <<json>>

Die Python Scripte müssen pro Rolle definiert werden. Deswegen muss diese Schnittstelle so flexibel gehandhabt werden.

MVP II

Registrierung

  • Registrierungs via Double Opt In via Email
  • Einstellung ob registrierung möglich ist oder nur durch admin

Nutzermanagement

Die Schnittstellen aus MVP II sollen im Frontend angezeigt werden

MVP III

Voucher

  • Ein Voucher soll bei der Registrierung eingegeben werden können.
  • Je nach Voucher nutzer mit den zu den voucher passenden rechten angelegt z.B. Storage space
  • Es soll implementiert werden, dass ein konfigurationsparameter registration existiert. Valide Werte: deactivated, with_voucher, open_for_everybody
  • Business Case: Brauchen das zur Werbung am Anfang

MVP IV

Bezahlsystem

  • Ein Bezahlsystem wird implementiert

Ein paar Fragen/Anmerkungen (damit ich das nachher nicht vergesse):

  • Zu den Details unter MVP I, z.B. einen Nutzernamen (lediglich buchstaben, keine sonderzeichen, zahlen). Nur zur Klarstellung: Ich nehme an du bist da flexibel und würdest nicht darauf beharren dass das genauso umgesetzt wird? Denn ich würde gerne einfach Open-Source-Libraries/Packages nutzen sofern möglich, und es kann sein dass die andere Regeln haben für Usernames
  • Bei MVP II: in einem späteren Draft sollte auch der User & die Group angegeben werden, die die Anwendung zur Ausführung dieser Skripte nutzen soll. Ist aber erst mal nicht wichtig, da Implementationsdetail.
  • Bei MVP II: meta.yml - die genaue Struktur müsste man wahrscheinlich überdenken wenn wir an diesem Meilenstein angekommen sind - aber der Grundgedanke ist angekommen und ergibt auch Sinn :+1:
  • Hat es ein Grund, dass das Vouchersystem vor dem Bezahlsystem implementiert werden soll? Oder können wir das tauschen wenn wir feststellen dass wir dadurch schneller sind?
1 Like

Zu den offenen Punkten:

Nutzername

Darauf beharre ich- Mehr oder weniger :smile: Bzw. Zahlen und Buchstaben geht auch. Vielleicht gehen auch “-” und “_”. Mehr geht aber definitiv nicht.

Der Grund dafür ist, dass der Nutzername auch für die übergreifenden Anwendungen benutzt wird z.B. für mastodon @nutzername@mastodon.cymais.cloud, für Matrix @nutzername:matrix.cymais.cloud, für Email nutzername@cymais.cloud.

Vielleicht können wir die Nutzernamen auf Grund der verschiedenen aufbauten auch später via proxy kürzen, so das bei mastodon @nutzername@cymais.cloud, bei matrix @nutzername:cymais.cloud und für mail nutzername@cymais.cloud benutzt werden kann.

Dadurch das wir den Nutzernamen am Anfang sehr restriktiv handhaben sparen wir uns ein mapping für die anderen Netzwerke, reduzieren technische Schuld und begrenzen die Komplexität.

ChatGPT sagt mir zum Nutzernamen folgendes:

Vouchersystem

Wir müssen die Vouchers an unsere Geschäfs- und Werbepartner ausgeben, damit die sich einen Account einrichten können und die Software direkt testen können. Außerdem ist das Bezahlsystem für die SaaS Accounts gedacht, also für den B2C Bereich. B2B rechnen wir anders ab. Unsere Cash Cow wird aber der B2B Markt sein. Von daher müssen wir erst alles für B2B fertig stellen :slight_smile:

@kevinveenbirkenbach So stelle ich mir die folgenden Registrierungs-User-Flows vor. Magst du bitte kurz drüber lesen und mir ein Feedback geben ob das so okay ist? Danke!

Erstmalige Einrichtung

  1. Wir setzen die Software auf.
  2. Wir erstellen das Team und den Team-Owner-Account (1), ohne den Nutzername und das Passwort zu setzen.
  3. Der Team Owner bekommt per Email eine Einladung mit einem Link, der ihn auf eine Seite weiterleitet wo er seine gewünschte Nutzername-Passwort-Kombination eingeben kann

Mitarbeiter hinzufügen durch Team Owner

  1. Der Team Owner kann über die Anwendung seine Mitarbeiter hinzufügen
    • Offene Frage: müssen wir das auch machen können? (falls der Kunde das nicht selber machen möchte?)
  2. Wenn ein Mitarbeiter hinzugefügt wird, bekommt er eine Einladung mit der er seine gewünschte Nutzername-Passwort-Kombination setzen kann
  3. Offene Frage: wollen wir hier noch eine Freischaltung durch einen Admin notwendig machen? oder hat sich das denn eh erledigt, weil der Team Owner ja diese Leute eh ins System einpflegen muss.

Mitarbeiter registrieren sich selber

  1. Der Mitarbeiter registriert sich.
  2. Ein Admin muss den Mitarbeiter freischalten

(1): Team Owner != Admin. Vermutlich wird der Team Owner derjenige sein der innerhalb des Unternehmens als Ansprechpartner für dieses System fungiert. Er kann dann beliebig viele Personen zu Admins ernennen. Was Team-Owner und Admins können und nicht können dürfen, können wir natürlich selber ändern im Code.

Zu 1:

Offene Frage: müssen wir das auch machen können? (falls der Kunde das nicht selber machen möchte?)

Grundsätzlich sollten wir folgendes im Hinterkopf behalten:
Zu einen sollten wir die Software so denken, dass wir sie als Full-Service Agentur betreuen können. Das bedeutet aber nicht, dass solche Aufgaben nur mit Adminrechten Ausgeführt werden. Beispiel: Unser “King of Kink” möchte Nutzer moderieren, oder bestimmte CRUD Befehle auf diese ausführen.

Am besten wir machen folgendes:

Nutzerstruktur

  • 1 Nutzer hat n parents
  • 1 Nutzer hat n childs
  • 1 Nutzer gehört zu 1:n gruppen

Nutzer hat alle CRUD rechte über alle kinder und kindeskinder

Gruppenstruktur
Zudem ist es glaube ich für den Unternehmenskontext zusätzlich noch sinnvoll Gruppen zu definiere:

  • 1 Gruppe hat n subgruppen
  • 1 Gruppe hat n übergruppen
  • 1 Gruppe hat n Mitglieder
  • 1 Gruppe hat n Owner

Owner können CRUD auf alle Gruppen und Mitglieder der eigenen und der Subgruppen ausführen.

Zu 2:
Nutzername sollte durch Team Owner definierbar, oder frei wählbar sein. Ggf. haben Unternehmen policies wie sie die Nutzernamen definieren.

Ich denke folgendes ist sinnvoll:

  • Einladungslink wird via Email versenden
  • Einladungslink wird zudem als url und mit QR code angezeigt → Dann können nämlich Team Leads direkt den Account mit den Mitarbeitern zusammen anlegen sollten sie im Office sein.

Bzgl: Mitarbeiter registrieren sich selber

Ich würde semantisch alles als Nutzer und nicht als Mitarbeiter im Hinterkopf behalten. Der Grund dafür ist:

Wir werden die Software als SaaS für Communities z.B. “Jamies Kinkkingdom” anbieten. In diesem Fall ist haben wir unseren King of King :crown: (Alle Nutzer leiten sich von ihm ab, er ist Gott :church: :wink: ) und seine Kronprinzen (sind direkte Kinkkingkinder). Der King kann alle moderieren und die Kronprinzen nur die Leibeigenen die Ihnen unterstehen. Die Kinder der Kronprinzen haben wiederum die Herrschaft über alle Ihre Kinder… Du erkennst die Idee :imp:

Zusätzlich haben wir die Gruppen die selbst verwaltet sind. Unterliegen natürlich trotzdem dem feudalistischen Herrschaftssystem und sind von Kinkies gnaden, haben aber auch eine eigene Selbstverwaltung (Gruppen Owner) die entscheiden wer Mitglied ist und wer nicht.

Mit dem Modell können wir ziemlich gut Herrschafts- und Hierarchiestrukturen in Firmen aber auch in Communities abbilden. Da hat sich das MEW 21 Studium gelohnt.

Ich weiß aber noch nicht in wie weit das schon in LDAP implementiert ist und wie weit du das im SaaSy implementieren musst. Bin da noch in der Recherche. Siehe auch CyMaIS LDAP Implementierung Documentation

PS:
Um die Frage metaphorisch zu beantworten:

  • Leibeigene Registrieren sich selbst mit Double Opt In
  • Leibeigene Registrieren sich selbst mit Single Opt In
  • Leibeigene Registrieren sich, der König muss aber zustimmen
  • Der König läd neue Leibeigene in sein reich ein, diese müssen aber zustimmen

Also vier Modi:

  • Single Opt In
  • Double Opt In
  • Freigabe erforderlich

Am besten ist es wenn die Gruppenowner leute einladen und die anfragen von Mitgliedern die sie, oder ein Co-Owner zu ihrer Gruppe eingeladen hat moderieren können. Also Gruppenowner haben immer alle CRUD Rechte auf die Eigene und Subgruppen und die entsprechende Moderation.

Call mit Kevin am 22.12.2023:

  • Die von Kevin beschriebene Nutzerstruktur lässt sich gut mit RBAC realisieren
    • Wir setzen von Beginn an auf RBAC.
    • Wie das konkret implementiert wird ist noch offen. Wichtig ist nur, dass diese Rechteverwaltung ermöglicht wird über eine Oberfläche die den Administratoren zugänglich ist.
  • Der Team Owner kann Nutzernamen nur dann festlegen, wenn dieser auch die User selber ins System einpflegt.
  • Marco wird ein Diagramm erstellen mit den Kern-User-Flows und dieses an Kevin schicken. Das Endergebnis soll ein Diagramm sein, das die verschiedenen User-Flows und ihre Schritte verständlich beschreibt. Dies soll sicherstellen, dass wir ein gemeinsames Verständnis und eine klare Vorstellung von diesen Abläufen haben.
1 Like

@kevinveenbirkenbach ich habe dir eine Einladung zu Miro geschickt. Hier findest du den Board mit den Flows: Miro | Online Whiteboard for Visual Collaboration

1 Like

Perfekt! Der Workflow sieht sehr gut aus. Kannst du so umsetzen :kiss: :heartpulse: :smiling_face_with_three_hearts:

Hier ist das entsprechende Epic in dem Features und Stories hinterlegt werden können: Sign in | OpenProject

Können diesen Thread aber trotzdem gerne weiter zum brainstormen und diskutieren nutzen :slight_smile: