Merge remote-tracking branch 'origin/ZUG-Patch' into julian-patch-1
This commit is contained in:
commit
d82ed4c7f6
279
pflichtenheft.md
279
pflichtenheft.md
|
|
@ -155,280 +155,19 @@ Redundanzeigenschaften Bespr. Mit Hr. Prof. Gürth
|
|||
| **CMS**: <br>-Das System soll einen redaktionellen Schülerzugagng bieten, damit die Diplomarbeiten von Schülern selbst eingepflegt werden können.<br> -Entwicklung geschieht in Themes und Modules </p><p> <b> Technologien und Tools:</b> <br> -Oqtane| SW-3 |
|
||||
| **Sicherheit und administrativer Zugriff:** <br> Der Administrative zugriff auf das System geschieht über eine SSH Verbindung, welche nur duch eine VPN (Wireguard) aufgebaut werden kann. Die Authentifizierung (der VPN und SSH) wird über Schlüsselpaare gemacht, um sicherer gegenüber bruteforce Angriffe zu sein. <br> Der Zugriff auf die Anwendung und die Infrastruktur muss jederzeit gegeben sein. Dies kann durch die Implementierung von:</p><ul><li>SSH-Zugriff für Administratoren</li><li>VPN-Verbindung (Virtual Private Network) für eine sichere und verschlüsselte Verbindung</li><li>Zugriffskontrolle und Authentifizierung, um den Zugriff auf autorisierte Personen zu beschränken</li></ul> erreicht werden. | SW-4 |
|
||||
|
||||
|
||||
## Zugriffsverwaltung
|
||||
|
||||
| Anforderung | ID |
|
||||
| --- | --- |
|
||||
| **Benutzername und Passwort Authentifizierung**: <br> **Im Frontend**: <br> Die Benutzername- und Passwort-Authentifizierung ermöglicht es Nutzern, sich in einer Anwendung zu identifizieren, indem sie ihre Anmeldedaten über ein Formular eingeben. Das Frontend sendet die Daten sicher an das Backend, das die Authentifizierung übernimmt. Bei erfolgreicher Anmeldung erhält der Nutzer Zugriff auf geschützte Bereiche der Anwendung. <br> **Vorraussetzungen**: <br><ol><li>Backend-Anforderungen <ul><li>Mechanismen zur Passwort-Validierung und Token-Generierung (z. B. JWT).</li><li>HTTPS für sichere Datenübertragung.</li></ul></li><li>Frontend-Anforderungen <ul><li>Möglichkeit zur Verarbeitung und sicheren Übertragung der Eingaben.</li><li>Mechanismus zur Speicherung von Authentifizierungsdaten (z. B. Tokens).</li></ul></li></ol> **Diese gelten für alle folgenden Punkte!** <br> **Benötigte Komponenten**: <ol><li>Login-Formular: <ul><li>Eingabefelder für Benutzername und Passwort.</li><li>Submit-Button.</li><li>Fehleranzeige bei ungültigen Eingaben oder falschen Daten.</li></ul></li><li>HTTP-Client: <ul><li>Zum Senden von Authentifizierungsanfragen an das Backend (RestAPI).</li></ul></li><li>Token-Management: <ul><li>Speicherung von JWTs (z. B. im localStorage oder Cookies).</li></ul></li><li>Routing: <ul><li>Weiterleitung zu geschützten Seiten nach erfolgreicher Anmeldung.</li><li>Zugangsbeschränkung zu sensiblen Bereichen der App.</li></ul></li></ol><br> **Technologien**: <ol><li>Framework: <ul><li>C#</li><li>HTML</li></ul></li><li>HTTP-Anfragen: <ul><li>RestAPI</li></ul></li><li>Sicherheitsmaßnahmen: <ul><li>HTTPS</li></ul></li><li>Styling: <ul><li>Eigenes CSS</li></ul></li><li>Token-Handling: <ul><li>JWT</li></ul></li><li>Datenbank: <ul><li>PostgreSQL</li></ul></li></ol> **Diese gelten für alle folgenden Punkte!**<br><br>**Backend:**<br>Überprüfung der empfangenen Anmeldedaten: Zunächst wird nach vorhandenen Benutzernamen gesucht.<br> Passwortüberprüfung: Anschließend wird das eingegebene Passwort mit den Daten in der Datenbank verglichen. | ZUG-1 |
|
||||
|
||||
<table><tbody>
|
||||
<tr><td style="text-align: left"><p><strong><b>Passwort zurücksetzen</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
Die Passwort-Zurücksetzen-Funktion im Frontend ermöglicht es Benutzern, über eine Benutzeroberfläche einen Token-basierten Prozess zur Passwortänderung zu starten.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Eingabefeld für die E-Mail-Adresse.</p><p>
|
||||
2. Formular zur Eingabe des neuen Passworts nach Token-Bestätigung.</p><p>
|
||||
3. Fehler- und Erfolgsmeldungen zur Benutzerführung.
|
||||
</p><p>
|
||||
|
||||
</p>
|
||||
<p>Backend:</p>
|
||||
<p>Passwortreset-Funktion
|
||||
E-Mail-Eingabe: Benutzer geben ihre E-Mail-Adresse ein, um einen Passwortreset anzufordern.
|
||||
E-Mail-Versand
|
||||
Token: Ein einmaliger, zeitlich begrenzter Token wird generiert und an die E-Mail-Adresse gesendet.
|
||||
Sicherheitsanforderungen
|
||||
Token-Generierung: Sicherer Algorithmus zur Token-Generierung.
|
||||
Link-Inhalt: Der Link enthält keine sensiblen Informationen.
|
||||
Datenbankoperationen
|
||||
Passwort-Hash: Der neue Passwort-Hash wird in der Datenbank gespeichert und überschreibt den alten Eintrag.
|
||||
Fehlerbehandlung
|
||||
Fehlermeldungen:
|
||||
Bei nicht registrierter E-Mail.
|
||||
Bei abgelaufenem Token.
|
||||
Protokollierung
|
||||
Anfragen: Alle Passwortreset-Anfragen werden protokolliert.</p></td>
|
||||
|
||||
<td><p>ZUG-2</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>Rollen</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
Die Implementierung von Rollen im Frontend dient der Steuerung von Benutzerzugriffen und Funktionen basierend auf deren Berechtigungen. Rollen legen fest, welche Inhalte und Aktionen für bestimmte Benutzergruppen sichtbar oder ausführbar sind.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Rollenbasierte Navigation </p><p>
|
||||
2. Zugriffskontroll-Guard </p><p>
|
||||
3. UI-Elemente basierend auf Benutzerrolle
|
||||
</p><p>
|
||||
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>Rollendefinition
|
||||
Rollen: Definition von Rollen (z.B. Administrator, Benutzer, Gast) mit spezifischen Berechtigungen.
|
||||
Datenbankstruktur
|
||||
Datenbanktabelle: Entwurf einer Tabelle zur Speicherung von Rollen und deren Berechtigungen.
|
||||
Rollenvergabe
|
||||
Funktionen: Implementierung von Funktionen zur Zuweisung und Entziehung von Rollen an Benutzer im Backend.
|
||||
Berechtigungsprüfung
|
||||
Middleware/Funktion: Entwicklung einer Middleware oder Funktion, die bei jeder Anfrage überprüft, ob der Benutzer die erforderlichen Berechtigungen hat.
|
||||
Sicherheitsanforderungen
|
||||
Autorisierung: Sicherstellen, dass nur autorisierte Benutzer (z.B. Administratoren) Rollen ändern oder zuweisen können.
|
||||
Protokollierung
|
||||
Änderungen: Implementierung von Protokollierungsmechanismen für Änderungen an Rollen und Berechtigungen zur Nachverfolgbarkeit.</p></td>
|
||||
|
||||
<td><p>ZUG-3</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>Benutzerverwaltung (für Admins)</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
Die Benutzerverwaltung erlaubt Administratoren, Benutzerkonten zu verwalten, einschließlich Erstellung, Bearbeitung, Aktivierung/Deaktivierung und Löschung von Benutzern sowie Zuweisung von Rollen und Berechtigungen.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Liste der Benutzer mit Rollen und Status </p><p>
|
||||
2. Buttons zum Bearbeiten und Löschen von Benutzern </p><p>
|
||||
3. Such- und Filterfunktionen für Benutzer
|
||||
</p><p>
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>Datenbankoperationen:
|
||||
Alle Änderungen, die über die Weboberfläche im Admin-Bereich vorgenommen werden, müssen über definierte Backend-API-Endpunkte in der Datenbank gespeichert werden.
|
||||
Zugriffssteuerung:
|
||||
Implementierung einer strengen Zugriffssteuerung, die sicherstellt, dass nur autorisierte Benutzer (z.B. Administratoren) Änderungen vornehmen können.
|
||||
Berechtigungsprüfung:
|
||||
Vor jeder Datenbankoperation muss eine Überprüfung der Benutzerrollen und -berechtigungen erfolgen, um sicherzustellen, dass der Benutzer die erforderlichen Rechte hat.
|
||||
Validierung der Eingaben:
|
||||
Alle Eingaben, die über die Weboberfläche an das Backend gesendet werden, müssen validiert werden, um sicherzustellen, dass sie den erwarteten Formaten und Werten entsprechen.
|
||||
Protokollierung von Änderungen:
|
||||
Alle Änderungen, die im Admin-Bereich vorgenommen werden, müssen protokolliert werden, um eine Nachverfolgbarkeit und Auditierung zu ermöglichen.
|
||||
Sicherheitsmaßnahmen:
|
||||
Implementierung von Sicherheitsmaßnahmen wie Rate Limiting und IP-Whitelisting, um unbefugte Zugriffe zu verhindern.
|
||||
Fehlerbehandlung:
|
||||
Bereitstellung von klaren Fehlermeldungen und Handhabung von unerwarteten Situationen, um die Integrität der Daten zu gewährleisten.</p></td>
|
||||
<td><p>ZUG-4</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>Einladung an die EDU-Adresse (Phase 2)</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
In Phase 2 wird die Möglichkeit geschaffen, Benutzern eine Einladung zur Registrierung oder Teilnahme über eine EDU-E-Mail-Adresse zu senden. Diese Einladung erfolgt in Form einer E-Mail, die den Benutzer zur Anmeldung auf der Plattform einlädt.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Eingabefeld für die EDU-E-Mail-Adresse </p><p>
|
||||
2. Button zum Versenden der Einladung </p><p>
|
||||
3. Bestätigungs- und Fehlermeldungen für den Versand
|
||||
</p><p>
|
||||
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>Einladungserstellung:
|
||||
Implementierung einer Funktion zur Erstellung einer Einladung, die alle erforderlichen Informationen (z.B. Empfänger, Betreff, Nachricht, Datum, Uhrzeit) erfasst.
|
||||
Datenbankintegration:
|
||||
Speichern der Einladung in der Datenbank, einschließlich aller relevanten Details und des Status (z.B. erstellt, versendet).
|
||||
E-Mail-Vorlage:
|
||||
Erstellung einer E-Mail-Vorlage, die die Einladung in einem ansprechenden Format darstellt.
|
||||
E-Mail-Versand:
|
||||
Implementierung einer Funktion, die die Einladung per E-Mail an den vorgesehenen Empfänger sendet, einschließlich der Verwendung eines E-Mail-Dienstes (z.B. SMTP-Server).
|
||||
Berechtigungsprüfung:
|
||||
Sicherstellen, dass nur autorisierte Benutzer (z.B. Administratoren) Einladungen erstellen und versenden können.
|
||||
Fehlerbehandlung:
|
||||
Implementierung von Mechanismen zur Fehlerbehandlung, um sicherzustellen, dass der Benutzer über den Erfolg oder das Scheitern des E-Mail-Versands informiert wird.
|
||||
Protokollierung:
|
||||
Protokollierung aller Einladungen, die erstellt und versendet wurden, um eine Nachverfolgbarkeit zu gewährleisten.
|
||||
Eingabever validation:
|
||||
Validierung der Eingaben (z.B. E-Mail-Adresse, Datum) vor der Erstellung und dem Versand der Einladung, um sicherzustellen, dass sie korrekt sind.</p></td>
|
||||
<td><p>ZUG-5</p></td></tr>
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>Magic Link Authentifizierung</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
Die Magic Link Authentifizierung ermöglicht es Benutzern, sich ohne Passwort anzumelden, indem sie auf einen Link klicken, der ihnen per E-Mail zugeschickt wird. Dieser Link ist temporär und führt den Benutzer direkt zur Anwendung, wenn er gültig ist.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Eingabefeld für die E-Mail-Adresse</p><p>
|
||||
2. Button zum Anfordern des Magic Links</p><p>
|
||||
3. Weiterleitung zur Bestätigungsseite nach Klick auf den Magic Link
|
||||
</p><p>
|
||||
|
||||
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>
|
||||
Benutzerregistrierung
|
||||
Registrierungsfunktion: Implementierung einer Funktion zur Registrierung potenzieller Benutzer, die ihre E-Mail-Adresse und andere erforderliche Informationen erfasst.
|
||||
E-Mail-Versand
|
||||
E-Mail mit Authentifizierungslink: Nach der Registrierung muss eine E-Mail an die angegebene Adresse gesendet werden, die einen Authentifizierungslink enthält.
|
||||
Link-Generierung
|
||||
Token: Der Authentifizierungslink muss einen einmaligen, kryptografisch sicheren Token enthalten, der mit dem Benutzerkonto verknüpft ist und eine begrenzte Gültigkeitsdauer hat (z.B. 24 Stunden).
|
||||
Datenbankeintrag
|
||||
Speicherung: Der Token und der Status der Authentifizierung müssen in der Datenbank gespeichert werden, um die Gültigkeit des Links zu überprüfen.
|
||||
Link-Verifizierung
|
||||
Token-Überprüfung: Implementierung einer Funktion, die den Token überprüft, wenn der Benutzer auf den Link klickt, um sicherzustellen, dass er gültig und nicht abgelaufen ist.
|
||||
Benutzeraktivierung
|
||||
Aktivierung: Nach erfolgreicher Verifizierung des Tokens muss das Benutzerkonto aktiviert werden.
|
||||
Fehlerbehandlung
|
||||
Fehlermeldungen: Bereitstellung von klaren Fehlermeldungen, wenn der Token ungültig oder abgelaufen ist, und gegebenenfalls die Möglichkeit zur erneuten Anforderung des Authentifizierungslinks.
|
||||
Protokollierung
|
||||
Nachverfolgbarkeit: Protokollierung aller Authentifizierungsanfragen und -versuche.
|
||||
</p></td>
|
||||
|
||||
<td><p>ZUG-6</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>2FA Authentifizierung (Phase 2)</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
In Phase 2 wird die Zwei-Faktor-Authentifizierung (2FA) implementiert, um die Sicherheit des Benutzerkontos zu erhöhen. Nach der Eingabe des Benutzernamens und Passworts wird ein zweiter Authentifizierungsfaktor benötigt, wie ein einmaliger Code, der an das Handy des Benutzers gesendet wird.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Eingabefeld für den OTP (One-Time-Password)</p><p>
|
||||
2. Button zur Bestätigung des OTPs</p><p>
|
||||
3. Fehler- und Erfolgsmeldungen für die OTP-Verifizierung
|
||||
</p><p>
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>Anmeldedatenüberprüfung:
|
||||
Nach der Eingabe der Anmeldedaten (Benutzername und Passwort) muss das System die Anmeldedaten validieren und überprüfen.
|
||||
Code-Generierung:
|
||||
Implementierung einer Funktion zur Generierung eines zeitlich begrenzten Codes (z.B. TOTP - Time-based One-Time Password), der auf einem anderen Gerät (z.B. Smartphone) generiert wird.
|
||||
Code-Übermittlung:
|
||||
Der generierte Code muss über eine sichere Kommunikationsoberfläche (z.B. Push-Benachrichtigung, SMS oder E-Mail) an den Benutzer gesendet werden.
|
||||
Benutzereingabe:
|
||||
Der Benutzer muss die Möglichkeit haben, den erhaltenen Code in die Anmeldemaske einzugeben, um seine Identität zu bestätigen.
|
||||
Code-Überprüfung:
|
||||
Implementierung einer Funktion zur Überprüfung des eingegebenen Codes gegen den generierten Code, um sicherzustellen, dass er korrekt und innerhalb der Gültigkeitsdauer ist.
|
||||
Fehlerbehandlung:
|
||||
Bereitstellung von klaren Fehlermeldungen, wenn der eingegebene Code ungültig oder abgelaufen ist, sowie die Möglichkeit, einen neuen Code anzufordern.
|
||||
Sicherheitsanforderungen:
|
||||
Sicherstellen, dass die Kommunikation zwischen dem Server und dem Gerät des Benutzers sicher ist (z.B. durch Verschlüsselung).
|
||||
Protokollierung:
|
||||
Protokollierung aller Anmeldeversuche und der Verwendung von Codes zur Nachverfolgbarkeit und zur Erkennung von potenziellen Sicherheitsvorfällen.</p></td>
|
||||
|
||||
<td><p>ZUG-7</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>OAuth (Phase 2)</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
In Phase 2 wird die OAuth-Authentifizierung implementiert, die es Benutzern ermöglicht, sich über Drittanbieter wie Google, Facebook oder andere Plattformen anzumelden. Dabei wird der Benutzer direkt zu einer externen OAuth-Plattform weitergeleitet, um sich zu authentifizieren, und anschließend wieder zurück zur Anwendung.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Button für die Auswahl des OAuth-Anbieters (z. B. Google, Facebook)</p><p>
|
||||
2. Weiterleitung zur OAuth-Anmeldeseite des Anbieters</p><p>
|
||||
3. Empfang und Verarbeitung des Tokens nach erfolgreicher Anmeldung
|
||||
</p><p>
|
||||
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>OAuth 2.0 Integration:
|
||||
Implementierung des OAuth 2.0-Protokolls zur Authentifizierung über LinkedIn. Dies umfasst die Registrierung der Anwendung bei LinkedIn und den Erhalt der erforderlichen Client-ID und Client-Secret.
|
||||
Benutzeranmeldung:
|
||||
Bereitstellung eines Endpunkts, über den Benutzer sich mit ihrem LinkedIn-Account anmelden können. Dies sollte einen Redirect zur LinkedIn-Login-Seite und die anschließende Rückleitung zur eigenen Anwendung nach erfolgreicher Authentifizierung umfassen.
|
||||
Token-Verwaltung:
|
||||
Nach erfolgreicher Authentifizierung muss das Backend den von LinkedIn erhaltenen Access-Token speichern, um zukünftige Anfragen an die LinkedIn-API zu ermöglichen.
|
||||
Mapping von LinkedIn-Accounts:
|
||||
Implementierung einer Datenbanktabelle, die das Mapping zwischen LinkedIn-Accounts (z.B. LinkedIn-ID) und den internen Benutzerkonten in der eigenen Anwendung speichert.
|
||||
Profilabgleich (Zukünftige Ausbaustufe):
|
||||
In einer späteren Phase sollte eine Funktion implementiert werden, die es ermöglicht, das LinkedIn-Profil des Benutzers abzurufen und mit dem eigenen Benutzerprofil abzugleichen. Dies könnte Informationen wie Name, E-Mail-Adresse, Berufserfahrung und Fähigkeiten umfassen.
|
||||
Sicherheitsanforderungen:
|
||||
Sicherstellen, dass alle Daten, die von LinkedIn abgerufen werden, sicher gespeichert und verarbeitet werden, um die Privatsphäre der Benutzer zu schützen.
|
||||
Fehlerbehandlung:
|
||||
Implementierung von Mechanismen zur Fehlerbehandlung, um mit möglichen Problemen bei der Authentifizierung oder beim Abrufen von Daten von LinkedIn umzugehen.
|
||||
Protokollierung:
|
||||
Protokollierung aller Authentifizierungsversuche und der zugehörigen LinkedIn-Daten, um eine Nachverfolgbarkeit und Analyse von Anmeldeaktivitäten zu ermöglichen.</p></td>
|
||||
<td><p>ZUG-8</p></td></tr></tbody></table>
|
||||
| **Benutzername und Passwort Authentifizierung**: <br> **Im Frontend**: <br> **Beschreibung**: <br> Die Benutzername- und Passwort-Authentifizierung ermöglicht es Nutzern, sich in einer Anwendung zu identifizieren, indem sie ihre Anmeldedaten über ein Formular eingeben. Das Frontend sendet die Daten sicher an das Backend, das die Authentifizierung übernimmt. Bei erfolgreicher Anmeldung erhält der Nutzer Zugriff auf geschützte Bereiche der Anwendung. <br> **Benötigte Komponenten**: <li> Login-Formular sie enthält Eingabefelder für Benutzername und Passwort sowie einen Login-Button. </li><li> API-Service dieser sendet die Anmeldedaten sicher an das Backend und verarbeitet die Antwort. </li><li> Token-Speicherung & Weiterleitung sie speichert das Authentifizierungstoken und leitet den Nutzer nach erfolgreicher Anmeldung weiter. </li> <br><br><br>**Backend:**<br>Überprüfung der empfangenen Anmeldedaten: Zunächst wird nach vorhandenen Benutzernamen gesucht.<br> Passwortüberprüfung: Anschließend wird das eingegebene Passwort mit den Daten in der Datenbank verglichen. | ZUG-1 |
|
||||
| **Passwort zurücksetzen**: <br> **Im Frontend**: <br> **Beschreibung**: <br> Die Passwort-Zurücksetzen-Funktion im Frontend ermöglicht es Benutzern, über eine Benutzeroberfläche einen Token-basierten Prozess zur Passwortänderung zu starten. <br> **Benötigte Komponenten**: <li> Eingabefeld für die E-Mail-Adresse </li><li> Formular zur Eingabe des neuen Passworts nach Token-Bestätigung </li><li> Fehler- und Erfolgsmeldungen zur Benutzerführung </li> <br> Backend: <br> Passwortreset-Funktion: Benutzer können ihre E-Mail-Adresse eingeben, um einen Passwortreset anzufordern.E-Mail-Versand: Die Anwendung sendet einen Link mit einem einmaligen, zeitlich begrenzten Token an die angegebene E-Mail-Adresse.Sicherheitsanforderungen: Der Token muss sicher generiert werden, und der Link darf keine sensiblen Informationen enthalten.Benutzeroberfläche: Die Oberfläche für den Passwortreset muss benutzerfreundlich sein und eine Bestätigung anzeigen.Datenbankoperationen: Der neue Passwort-Hash wird in der Datenbank gespeichert und überschreibt den alten Eintrag.Fehlerbehandlung: Geeignete Fehlermeldungen müssen angezeigt werden, wenn die E-Mail nicht registriert ist oder der Token abgelaufen ist.Protokollierung: Alle Passwortreset-Anfragen müssen protokolliert werden. <br> | ZUG-2 |
|
||||
| **Rollen**: <br> **Im Frontend**: <br> **Beschreibung**: <br> Die Implementierung von Rollen im Frontend dient der Steuerung von Benutzerzugriffen und Funktionen basierend auf deren Berechtigungen. Rollen legen fest, welche Inhalte und Aktionen für bestimmte Benutzergruppen sichtbar oder ausführbar sind. <br> **Benötigte Komponenten**: <li> Rollenbasierte Navigation </li><li> Zugriffskontroll-Guard </li><li> UI-Elemente basierend auf Benutzerrolle </li> <br> Backend: <br> Rollendefinition:Definieren von Rollen (z.B. Administrator, Benutzer, Gast) mit spezifischen Berechtigungen.Datenbankstruktur:Entwurf einer Datenbanktabelle zur Speicherung von Rollen und deren Berechtigungen.Rollenvergabe:Implementierung von Funktionen zur Zuweisung und Entziehung von Rollen an Benutzer im Backend.Berechtigungsprüfung:Entwicklung einer Middleware oder Funktion, die bei jeder Anfrage überprüft, ob der Benutzer die erforderlichen Berechtigungen für die angeforderte Aktion hat.Sicherheitsanforderungen:Sicherstellen, dass nur autorisierte Benutzer (z.B. Administratoren) Rollen ändern oder zuweisen können.Protokollierung:Implementierung von Protokollierungsmechanismen für Änderungen an Rollen und Berechtigungen zur Nachverfolgbarkeit. <br> | ZUG-3 |
|
||||
| **Benutzerverwaltung (für Admins)**: <br> **Im Frontend**: <br> **Beschreibung**: <br> Die Benutzerverwaltung erlaubt Administratoren, Benutzerkonten zu verwalten, einschließlich Erstellung, Bearbeitung, Aktivierung/Deaktivierung und Löschung von Benutzern sowie Zuweisung von Rollen und Berechtigungen. <br> **Benötigte Komponenten**: <li> Liste der Benutzer mit Rollen und Status </li><li> Buttons zum Bearbeiten und Löschen von Benutzern </li><li> Such- und Filterfunktionen für Benutzer </li> <br> Backend: <br> Datenbankoperationen:Alle Änderungen, die über die Weboberfläche im Admin-Bereich vorgenommen werden, müssen über definierte Backend-API-Endpunkte in der Datenbank gespeichert werden.Zugriffssteuerung:Implementierung einer strengen Zugriffssteuerung, die sicherstellt, dass nur autorisierte Benutzer (z.B. Administratoren) Änderungen vornehmen können.Berechtigungsprüfung:Vor jeder Datenbankoperation muss eine Überprüfung der Benutzerrollen und -berechtigungen erfolgen, um sicherzustellen, dass der Benutzer die erforderlichen Rechte hat.Validierung der Eingaben:Alle Eingaben, die über die Weboberfläche an das Backend gesendet werden, müssen validiert werden, um sicherzustellen, dass sie den erwarteten Formaten und Werten entsprechen.Protokollierung von Änderungen:Alle Änderungen, die im Admin-Bereich vorgenommen werden, müssen protokolliert werden, um eine Nachverfolgbarkeit und Auditierung zu ermöglichen.Sicherheitsmaßnahmen:Implementierung von Sicherheitsmaßnahmen wie Rate Limiting und IP-Whitelisting, um unbefugte Zugriffe zu verhindern.Fehlerbehandlung:Bereitstellung von klaren Fehlermeldungen und Handhabung von unerwarteten Situationen, um die Integrität der Daten zu gewährleisten. <br> | ZUG-4 |
|
||||
| **Einladung an die EDU-Adresse (Phase 2)**: <br> **Im Frontend**: <br> **Beschreibung**: <br> In Phase 2 wird die Möglichkeit geschaffen, Benutzern eine Einladung zur Registrierung oder Teilnahme über eine EDU-E-Mail-Adresse zu senden. Diese Einladung erfolgt in Form einer E-Mail, die den Benutzer zur Anmeldung auf der Plattform einlädt. <br> **Benötigte Komponenten**: <li> Eingabefeld für die EDU-E-Mail-Adresse </li><li> Button zum Versenden der Einladung </li><li> Bestätigungs- und Fehlermeldungen für den Versand </li> <br> Backend: <br> Einladungserstellung:Implementierung einer Funktion zur Erstellung einer Einladung, die alle erforderlichen Informationen (z.B. Empfänger, Betreff, Nachricht, Datum, Uhrzeit) erfasst.Datenbankintegration: Speichern der Einladung in der Datenbank, einschließlich aller relevanten Details und des Status (z.B. erstellt, versendet).E-Mail-Vorlage:Erstellung einer E-Mail-Vorlage, die die Einladung in einem ansprechenden Format darstellt.E-Mail-Versand:Implementierung einer Funktion, die die Einladung per E-Mail an den vorgesehenen Empfänger sendet, einschließlich der Verwendung eines E-Mail-Dienstes (z.B. SMTP-Server)Berechtigungsprüfung:Sicherstellen, dass nur autorisierte Benutzer (z.B. Administratoren) Einladungen erstellen und versenden können.Fehlerbehandlung:Implementierung von Mechanismen zur Fehlerbehandlung, um sicherzustellen, dass der Benutzer über den Erfolg oder das Scheitern des E-Mail-Versands informiert wird Protokollierung:Protokollierung aller Einladungen, die erstellt und versendet wurden, um eine Nachverfolgbarkeit zu gewährleisten.Eingabever validation:Validierung der Eingaben (z.B. E-Mail-Adresse, Datum) vor der Erstellung und dem Versand der Einladung, um sicherzustellen, dass sie korrekt sind. <br> | ZUG-5 |
|
||||
| **Magic Link Authentifizierung**: <br> **Im Frontend**: <br> **Beschreibung**: <br> Die Magic Link Authentifizierung ermöglicht es Benutzern, sich ohne Passwort anzumelden, indem sie auf einen Link klicken, der ihnen per E-Mail zugeschickt wird. Dieser Link ist temporär und führt den Benutzer direkt zur Anwendung, wenn er gültig ist. <br> **Benötigte Komponenten**: <li> Eingabefeld für die EDU-E-Mail-Adresse </li><li> Button zum Anfordern des Magic Links </li><li> Weiterleitung zur Bestätigungsseite nach Klick auf den Magic Link </li> <br> Backend: <br> Benutzerregistrierung:Implementierung einer Funktion zur Registrierung potenzieller Benutzer, die ihre E-Mail-Adresse und andere erforderliche Informationen erfasst.E-Mail-Versand:Nach der Registrierung muss eine E-Mail an die angegebene Adresse gesendet werden, die einen Authentifizierungslink enthält.Link-Generierung:Der Authentifizierungslink muss einen einmaligen, kryptografisch sicheren Token enthalten, der mit dem Benutzerkonto verknüpft ist undeine begrenzte Gültigkeitsdauer hat (z.B. 24 Stunden).Datenbankeintrag:Der Token und der Status der Authentifizierung müssen in der Datenbank gespeichert werden, um die Gültigkeit des Links zu überprüfen.Link-Verifizierung:Implementierung einer Funktion, die den Token überprüft, wenn der Benutzer auf den Link klickt, um sicherzustellen, dass er gültig und nicht abgelaufen ist.Benutzeraktivierung:Nach erfolgreicher Verifizierung des Tokens muss das Benutzerkonto aktiviert werden, und der Benutzer sollte auf eine Bestätigungsseite weitergeleitet werden.Fehlerbehandlung:Bereitstellung von klaren Fehlermeldungen, wenn der Token ungültig oder abgelaufen ist, und gegebenenfalls die Möglichkeit zur erneuten Anforderung des Authentifizierungslinks.Protokollierung:Protokollierung aller Authentifizierungsanfragen und -versuche, um eine Nachverfolgbarkeit zu gewährleisten. <br> | ZUG-6|
|
||||
| **2FA Authentifizierung (Phase 2)**: <br> **Im Frontend**: <br> **Beschreibung**: <br> In Phase 2 wird die Zwei-Faktor-Authentifizierung (2FA) implementiert, um die Sicherheit des Benutzerkontos zu erhöhen. Nach der Eingabe des Benutzernamens und Passworts wird ein zweiter Authentifizierungsfaktor benötigt, wie ein einmaliger Code, der an das Handy des Benutzers gesendet wird. <br> **Benötigte Komponenten**: <li> Eingabefeld für den OTP (One-Time-Password) </li><li> Button zur Bestätigung des OTPs </li><li> Fehler- und Erfolgsmeldungen für die OTP-Verifizierung </li> <br> Backend: <br>Anmeldedatenüberprüfung:Nach der Eingabe der Anmeldedaten (Benutzername und Passwort) muss das System die Anmeldedaten validieren und überprüfen.Code-Generierung:Implementierung einer Funktion zur Generierung eines zeitlich begrenzten Codes (z.B. TOTP - Time-based One-Time Password), der auf einem anderen Gerät (z.B. Smartphone) generiert wird.Code-Übermittlung:Der generierte Code muss über eine sichere Kommunikationsoberfläche (z.B. Push-Benachrichtigung, SMS oder E-Mail) an den Benutzer gesendet werden.Benutzereingabe:Der Benutzer muss die Möglichkeit haben, den erhaltenen Code in die Anmeldemaske einzugeben, um seine Identität zu bestätigen.Code-Überprüfung:Implementierung einer Funktion zur Überprüfung des eingegebenen Codes gegen den generierten Code, um sicherzustellen, dass er korrekt und innerhalb der Gültigkeitsdauer ist.Fehlerbehandlung:Bereitstellung von klaren Fehlermeldungen, wenn der eingegebene Code ungültig oder abgelaufen ist, sowie die Möglichkeit, einen neuen Code anzufordern.Sicherheitsanforderungen:Sicherstellen, dass die Kommunikation zwischen dem Server und dem Gerät des Benutzers sicher ist (z.B. durch Verschlüsselung).Protokollierung:Protokollierung aller Anmeldeversuche und der Verwendung von Codes zur Nachverfolgbarkeit und zur Erkennung von potenziellen Sicherheitsvorfällen. | ZUG-7|
|
||||
| **OAuth (Phase 2)**: <br> **Im Frontend**: <br> **Beschreibung**: <br> In Phase 2 wird die OAuth-Authentifizierung implementiert, die es Benutzern ermöglicht, sich über Drittanbieter wie Google, Facebook oder andere Plattformen anzumelden. Dabei wird der Benutzer direkt zu einer externen OAuth-Plattform weitergeleitet, um sich zu authentifizieren, und anschließend wieder zurück zur Anwendung. <br> **Benötigte Komponenten**: <li> Button für die Auswahl des OAuth-Anbieters (z. B. Google, Facebook) </li><li> Weiterleitung zur OAuth-Anmeldeseite des Anbieters </li><li> Empfang und Verarbeitung des Tokens nach erfolgreicher Anmeldung </li> <br> Backend: <br>OAuth 2.0 Integration:Implementierung des OAuth 2.0-Protokolls zur Authentifizierung über LinkedIn. Dies umfasst die Registrierung der Anwendung bei LinkedIn und den Erhalt der erforderlichen Client-ID und Client-Secret.Benutzeranmeldung:Bereitstellung eines Endpunkts, über den Benutzer sich mit ihrem LinkedIn-Account anmelden können. Dies sollte einen Redirect zurLinkedIn-Login-Seite und die anschließende Rückleitung zur eigenen Anwendung nach erfolgreicher Authentifizierung umfassen.Token-Verwaltung:Nach erfolgreicher Authentifizierung muss das Backend den von LinkedIn erhaltenen Access-Token speichern, um zukünftige Anfragen an die LinkedIn-API zu ermöglichen.Mapping von LinkedIn-Accounts:Implementierung einer Datenbanktabelle, die das Mapping zwischen LinkedIn-Accounts (z.B. LinkedIn-ID) und den internen Benutzerkonten in der eigenen Anwendung speichert.Profilabgleich (Zukünftige Ausbaustufe):In einer späteren Phase sollte eine Funktion implementiert werden, die es ermöglicht, das LinkedIn-Profil des Benutzers abzurufen und mit dem eigenen Benutzerprofil abzugleichen. Dies könnte Informationen wie Name, E-Mail-Adresse, Berufserfahrung und Fähigkeiten umfassen.Sicherheitsanforderungen:Sicherstellen, dass alle Daten, die von LinkedIn abgerufen werden, sicher gespeichert und verarbeitet werden, um die Privatsphäre der Benutzer zu schützen.Fehlerbehandlung:Implementierung von Mechanismen zur Fehlerbehandlung, um mit möglichen Problemen bei der Authentifizierung oder beim Abrufen von Daten von LinkedIn umzugehen.Protokollierung:Protokollierung aller Authentifizierungsversuche und der zugehörigen LinkedIn-Daten, um eine Nachverfolgbarkeit und Analyse von Anmeldeaktivitäten zu ermöglichen. | ZUG-8 |
|
||||
|
||||
## Hall of Fame (Phase 2)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user