Ich mach mal etwas freestyle, weil es noch kein Template hierfür gibt und irgendwie auch kein 001, aber ein 002...?

Hier mal so meine Ideen dazu, was der USS alles machen soll (und was nicht), sowie meine Ideen, wie man den konkret implementieren kann.

Funktion

Discord Link

Der User Self-Service soll primär Studenten die Möglichkeit bieten, ihren Discord-Account zu verknüpfen, und dadurch automatisch auf jedem der (AI/Info/ITS)-Guilds, in dem sie sind, eine entsprechende Studiengangs-Rolle zu bekommen. Jeder Guild kann danach selbst entscheiden, ob diese Rolle z.B. zusätzliche Channel freischaltet oder nicht. Dies ist out of scope für den USS, dieser weist nur die Rollen zu.

Sobald ein Student einen Discord-Account verknüpft hat, soll diesem Studenten der entsprechdende Account im USS angezeigt werden. Es soll auch die Möglichkeit geben, seinen Discord-Account wieder zu unlinken. Dadurch verliert er die Rollen auf jedem der Server. Es soll pro Student nur möglich sein, einen Discord-Account zu verknüpfen; mehrere Accounts pro Student werden nicht unterstützt.

Wenn ein User einen unserer Guilds joined, sollen ihm automatisch die korrekten Rollen zugewiesen werden, wenn er bereits seinen Account verknüpft hat. Wir brauchen also einen Gateway-Discord-Bot, nicht nur pures REST.

Zusätzlich könnte es möglich sein, dass auf jedem Guild ein entsprechender Nickname gesetzt wird. Auf dem AI-Guild haben wir das bisher so gemacht, dass dein Nickname gesetzt wird auf <Discord Username> | <Vorname> (das setzt natürlich voraus, dass der USS den Vornamen anständig kennt; siehe dazu auch den nächsten Funktionspunkt). Damit sind wir aber, soweit ich sehe, die einzigen, während Info/ITS kein solches Schema hat. Das Schema müsste also per Guild konfigurierbar/(de)aktivierbar sein.

Namen/Username setzen

Derzeit wird sowohl der Vorname als auch der Nachname einfach auf den vorderen Teil der Email gesetzt. Applikationen bekommen also beim Auslesen des name-Fields eine Abscheulichkeit wie adrian.paschkowski adrian.paschkowski präsentiert. Idealerweise sollte natürlich first_name/given_name auf den Vornamen und last_name/family_name auf den Nachnamen gesetzt werden.

Leider bekommen wir vom RUB-SSO nicht den Namen, sondern nur die Email; wir werden also so oder so den Namen "raten" müssen. Die Logik dafür könnte man im Studienwahl-Plugin certainly verbessern, aber es wird immer edge cases geben, oder auch Leute mit z.B. mehreren Vornamen präferieren einen anderen Namen. Deshalb sollte es Studenten möglich sein, ihren Namen im USS zu ändern.

Randnotiz: Es gibt bereits nativ in Keycloak die Möglichkeit, seinen Namen zu setzen. Derzeit ist dies aber noch so merkwürdig konfiguriert, dass der Vorname readonly ist, und der Nachname der user-editable volle Name ist. Ebenfalls zeigt Keycloak in der UI nicht an, welche der Felder man jetzt editieren kann und welche nicht, eine Fehlermeldung gibt es erst beim Absenden. Deswegen meinen Vorschlag, das im USS zu machen, und damit den Nutzern die konkreten Details weg zu abstrahieren, wie genau der Name intern gespeichert wird.

Wenn diese merkwürdige Nutzung von First/Lastname so bleiben soll, dann können wir meinetwegen auch preferred_username für den User-Provided Name nutzen.

Studiengangs-Wahl

Falls ein Student seinen Studiengang wechselt, oder ihn aus irgendeinem Grund falsch angegeben hat, sollte es dem Student möglich sein, seine Wahl zu ändern. Die Discord-Rollen eines eventuell verknüpften Accounts müssen dementsprechend geupdated werden.

Accountinformationen einsehen

Interessierten Studenten sollte es möglich sein, alle Informationen einzusehen, die wir in ihren Keycloak-Account speichern. Dazu gehören z.B. ihre Gruppen. Glücklicherweise kann das Keycaloak selber, das Frontend muss also nur auf https://auth.fs-its.rub.de/realms/fsr-ffi/account/ verlinken.

Non-Goals

Passwortänderung

Dat ist basically nen SSO-Proxy, da gibt nix eigenes Passwort.

2FA-Management

Ob man 2FA für Studenten jetzt anbietet oder nicht, ist in #3 und #5 zu diskutieren. So oder so ist das etwas, was Studenten in Keycloak direkt machen sollten, als das wir das Rad nochmal erfinden und noch eine UI dafür bauen.

Ersti-Management

Im AI-SSO geben wir allen Erstis eine Rolle. Wenn sie dann ihren Discord-Account verknüpfen, bekommen sie auf dem Server automatisch eine Ersti-Rolle. Am Ende des Semesters kann man dann über einen Button in unserem alten USS alle Ersti-Rollen sowohl im SSO als auch auf Discord purgen.

Mit dem neuen SSO würde es überhaupt schon daran scheitern, Studenten als Erstis zu identifizieren. Bisher funktionierte das nur, weil jeder seine Studienbescheinigung abgegeben hat oder in der Erstiwoche über einen separaten Bulk-Registrierprozess einen Erstiaccount bekommen hat. Deshalb macht das Management einer Ersti-Gruppe in Keycloak keinen Sinn. AI kann dies auch über self-assignable Rollen in Discord machen, und Info/ITS haben glaube ich nichtmal Ersti-Rollen.

Integration in den Signup Workflow

Es wäre ziemlich toll, den kompletten Signup Workflow über das USS zu leiten. D.h. nach erstmaligem Login über Keycloak werden Nutzer erst ins USS geleitet, um dort z.B. ihren Studiengang und ihren Namen wählen, bevor sie sich tatsächlich in eine Applikation anmelden können. Auf diesem Weg bekäme die Applikation dann auch direkt den richtigen Namen des Nutzers, statt wie bisher einfach den vorderen Teil der Email. Nachdem man all seine Daten eingegeben hat, würde man zur Applikation zurück geleitet werden.

Wie bereits auf Signal diskutiert, scheint es leider techisch schwierig zu sein, dies anständig in Keycloak zu integrieren, und Konsens war, die initiale Studiengangswahl erstmal in Keycloak zu lassen (und etwas zu themen). Es muss also einen anderen, trotzdem offentsichtlichen Weg geben, wie Studenten ins USS kommen und ihre Accountdaten (wie Name) fixen. In der Keycloak-Studiengangswahl sollte es mindestens einen fetten Button geben, der auf das USS verlinkt. Der sollte aber erst kommen, nachdem man seinen Studiengang gespeichert hat, weil sonst müsste man diesen beim Login in den USS erneut auswählen, weil man sich ins USS geklickt hat, bevor man die initiale Studiengangsform abgesendet hat.

Implemementierung

Es gibt bereits ein simples Typescript-Backend in https://gitlab.ruhr-uni-bochum.de/fsi/idm/self-service. Ich würde vorschlagen, dies weiter zu verwenden und um eine JSON-API zu erweitern. Diese API muss die oben erläuterten Funktionen supporten. Weiterhin wäre es vermutlich am einfachsten, den Discord-Bot mit ins gleiche Backend zu implementieren.
Soweit ich weiß, hatten @kosakpvg und @tobi geplant, dies zu machen?

Das Frontend schlage ich (@__) vor, in React/Typescript machen (because I like React). Das Design würde ich wieder in Hemera machen (mein selbst getauftes Design, wie schon auf https://auth.ai-rub.de/uss/ gesehen).

Diskussionsbedarf: Das Frontend und Backend wären dann zwei eigenständige Projekte, die per JSON-API miteinander kommunizieren. Am einfachsten wäre zwar, zwei separate Repos zu haben; dann hätte man eine einfache Dateistruktur und käme sich nicht gegenseitig in die Quere mit Commits. Allerdings müsste man dann immer zwei zusammenpassende Versionen finden, builden und deployen. Ich würde deswegen ein Monorepo mit Front- und Backend in zwei separaten Ordnern präferieren. Dann muss man nicht Commits/PRs über zwei Projekte hinweg machen, wenn man auf beiden Seiten was ändert, und jede Revision hat immer ein zusammenpassendes Front- und Backend.