Was passiert, wenn die Sitzung der Host-App zuerst endet?

Angenommen, ein Vertriebsmitarbeiter schließt in der Außendienst-App eine Kampagnenschulung ab. Die Akademie speichert den Abschluss, doch die Sitzung der Host-App ist bereits abgelaufen. Wenn die Prämienvergabe von dieser Sitzung abhängt, kann der Mitarbeiter eine Erfolgsmeldung sehen, während im Prämiensystem nichts ankommt.

Eine Anmeldung bedeutet kein gemeinsames Sitzungsende

Die NIST-Leitlinien zu föderierten Identitäten unterscheiden unabhängig verwaltete Anwendungssitzungen, auch wenn diese denselben Identitätsanbieter nutzen. (pages.nist.gov) Für die Sitzungsverwaltung eines eingebetteten LMS reicht ein erfolgreicher Anmeldetest deshalb nicht aus. Die Integration muss festlegen, welche Sitzung die jeweilige Aktion autorisiert und was passiert, wenn diese Berechtigung erlischt.

Vier Situationen machen die Systemgrenze sichtbar

Das Ende der Sitzung in der Host-App ist nur einer dieser Fälle. Auch die Sitzung der Akademie kann zuerst ablaufen, während die Host-App weiter nutzbar bleibt. Ein Netzwerkausfall kann das Speichern unterbrechen oder verhindern, dass eine Bestätigung ankommt. Ein Vertriebsmitarbeiter kann erst zurückkehren, wenn beide Sitzungen abgelaufen sind. Für jeden dieser Fälle muss das Verhalten gesondert festgelegt werden. Ein pauschaler Hinweis, sich erneut anzumelden, reicht nicht.

Gespeichert ist nicht gleich zugestellt

Bei der Synchronisierung des Lernfortschritts sollte klar unterschieden werden: Liegen die Daten nur auf dem Gerät, hat die Akademie sie gespeichert oder hat die Host-App die Ergebnisse bereits angenommen? Eine robuste Lösung speichert den Abschluss und einen Datensatz für die ausstehende Zustellung gemeinsam und dauerhaft, bevor sie das Ereignis versendet. Zertifikate sollten auf den dauerhaft gespeicherten Abschlussdatensatz verweisen. Eine Prämie sollte erst bestätigt werden, wenn die vereinbarte Bestätigung der Host-App vorliegt.

OAuth ermöglicht die Autorisierung von Diensten über Client-Credentials, ohne dass dafür eine Browsersitzung des Lernenden nötig ist. (rfc-editor.org) Soweit die Sicherheitsrichtlinien es zulassen, sollte das Backend für die Zustellung diese separate Berechtigung nutzen, statt eine geöffnete App-Ansicht vorauszusetzen. Regeln für die Abmeldung und den Widerruf von Berechtigungen müssen dennoch ausdrücklich festgelegt werden.

Bei erneuter Anmeldung muss die Identität erhalten bleiben, ohne Lerndaten auf andere Konten zu übertragen

Die Sitzungsverwaltung von OpenID Connect wertet eine veränderte zurückgemeldete Identität als Abmeldung des ursprünglichen Nutzers. (openid.net) Die Authentifizierung bei der Akademie-Integration sollte festlegen, wann Sitzungen erneuert werden, wie die sichtbare erneute Anmeldung abläuft und ab wann geschützte Aktionen pausieren. Gespeicherter Fortschritt darf nicht bedeuten, dass auch der Zugriff bestehen bleibt.

OpenID Connect verwendet issuer und subject gemeinsam als stabile Nutzerkennung. (openid.net) Die Integration sollte diese Identität dem richtigen Konto des Vertriebsmitarbeiters zuordnen. Noch ausstehende Datensätze müssen dem ursprünglichen Lernenden zugeordnet bleiben, wenn sich jemand anderes anmeldet.

Die HTTP-Semantik warnt davor, nicht idempotente Operationen ohne Schutzmaßnahmen automatisch zu wiederholen. (rfc-editor.org) Jedes Ergebnis sollte bei allen Übertragungsversuchen dieselbe Ereignis-ID behalten. Der Empfänger sollte diese ID speichern und die zugehörige Aktion im selben atomaren Schritt ausführen, damit eine erneute Zustellung keine weitere Prämie auslösen kann. Ereignis-IDs sollten einzelne Ereignisse kennzeichnen und nicht als Zugangsdaten für Sitzungen dienen. Für begrenzte Wiederholungsversuche braucht es einen Eskalationsweg, falls eine Zustellung ungeklärt bleibt.

Unterbrochene Abläufe gehören in die Abnahme

Eine Abnahmematrix sollte für jeden Fall die Meldung an die Lernenden, den dauerhaft gespeicherten Datensatz und die erwartete Wirkung in der Host-App festhalten.

• Die Sitzung der Host-App endet zuerst – der gespeicherte Abschluss bleibt erhalten und die Zustellung folgt den vereinbarten Regeln.
• Die Sitzung der Akademie endet zuerst – geschützte Aktionen pausieren, ohne den gespeicherten Lernfortschritt zurückzusetzen.
• Die Netzwerkverbindung bricht vor dem Speichern ab – die Oberfläche zeigt keine Bestätigung durch den Server an.
• Die Host-App speichert das Ergebnis, doch die Bestätigung geht verloren – eine erneute Zustellung löst keine zweite Prämie aus.
• Ein Vertriebsmitarbeiter kehrt nach Ablauf der Sitzung zurück – bevor sein persönlicher Lernstatus wiederhergestellt wird, wird seine Identität geprüft.

Die Vereinbarung zum Start regelt auch die Wiederherstellung

Für eine App-Learning-Integration sollte die Vereinbarung zu den Sitzungszuständen dokumentieren, wer für Zeitlimits verantwortlich ist, welche Grenzen für die Sitzungserneuerung gelten und wie Abmeldungen weitergegeben werden. Außerdem sollte sie festlegen, wo welche Daten gespeichert werden, welche Felder Ereignisse enthalten, was eine Bestätigung bedeutet und wie lange Daten für erneute Zustellversuche aufbewahrt werden. Für ungeklärte Ereignisse braucht es zudem eine namentlich benannte verantwortliche Person und ein Verfahren zum Datenabgleich.

Es geht nicht darum, jede Sitzung am Leben zu halten. Entscheidend ist, dass die Lerndaten auch nach Sitzungsende korrekt bleiben. Ein Vertriebsmitarbeiter sollte eine gültig abgeschlossene Schulung nicht wiederholen müssen, nur weil die Zustellung gescheitert ist. Und das für den Betrieb zuständige Team sollte nicht raten müssen, ob aus einem Abschluss ein Zertifikat, eine Verkaufsberechtigung oder eine Prämie geworden ist.