Zentrales Verzeichnis
Eine Identitätsschicht für Ronova-eigene Websites, Anwendungen und interne Werkzeuge.
Authentifizierung bleibt redirect-basiert, Sitzungen bleiben app-begrenzt und Berechtigungen bleiben explizit, statt über alle Oberflächen zu verlaufen.
Zentrales Verzeichnis
Jede Oberfläche teilt dieselbe Identitätsgrundlage, beantwortet aber eine andere Frage.
Live-Zugriff
Der öffentliche passkey-first-Login ist noch nicht aktiv. Für den ersten Owner-Bootstrap kann Ronova ID eine temporär erhöhte Sitzung aus einer bestehenden privaten Ronova-Admin-Sitzung ableiten.
Diese Brücke bleibt absichtlich eng: Sie verlangt die bestehende private Admin-Sitzung und erstellt nie ein gemeinsames Cookie für andere Domains.
Grundlage
Ronova ID ist die Identitätsgrundlage und kein dekoratives Login-Abzeichen. Hier beginnt Vertrauen, verengt sich und wird später wieder geprüft.
Eine Profilquelle, eine Besitzspur und ein Ort, an dem sichtbar wird, welche von Ronova betriebene Oberfläche nach Identität fragt.
Nützlich für öffentliche Seiten, experimentelle Apps und private Konsolen.
Jede Anwendung behält ihre eigene Sitzungshülle, damit die Anmeldung an einem Werkzeug nicht stillschweigend alle anderen freischaltet.
Kurzlebig für erhöhte Arbeit, ruhiger für risikoarme Ansichten.
Authentifizierung läuft über bewusste Redirects mit benanntem Rückweg und protokolliertem Grund der Anfrage.
Die Übergabe bleibt lesbar statt unsichtbar im Hintergrundzustand zu verschwinden.
Ablauf
Der Redirect-Weg soll vom ersten Antrag bis zur Rückkehr in die App ausdrücklich sichtbar bleiben.
Eine App sendet die besuchende Person mit Client-Namen, gewünschtem Umfang und Rückziel an Ronova ID.
Ronova ID zeigt, welcher Client gefragt hat, was er möchte und wohin nach der Freigabe zurückgeführt wird.
Es wird nur der angeforderte Umfang ausgestellt, und die entstehende Sitzung ist an genau diesen Client gebunden.
Die Anwendung läuft mit dem gewährten Identitätskontext weiter, während die Anfragekette für spätere Prüfung sichtbar bleibt.
Client-Katalog
Dieselbe Identitätsschicht kann sehr unterschiedliche Oberflächen bedienen, ohne so zu tun, als bräuchten alle denselben Zugriff.
Identitätsüberblick, Support-Routing und Kontoeinstiege teilen sich eine Vertrauensgrenze, ohne in einer einzigen breiten Sitzung zu verschwimmen.
Wenig Privileg, viel Klarheit.
Spielbezogene Anmeldung, Profilpräsenz, Speicherstände und Kontosupport können genau die benötigte Identität anfordern, ohne Admin-Macht zu erben.
Benutzerbezogener Zugriff.
Moderation, Support-Triage, Release-Governance und Audit-Suche bleiben getrennte Clients mit stärkeren Kontrollen.
Operativer Vertrauensbereich.
Governance
Identität bedeutet nicht nur hereinzukommen. Sie bedeutet auch zu belegen, wer gefragt, wer genehmigt und was sich danach geändert hat.
Berechtigungen bleiben lesbar statt vage. Ein Client soll nach Fähigkeiten wie Profildaten lesen, Support-Kontext öffnen oder Clients verwalten fragen.
Benannte Berechtigungen halten Freigaben verständlich.
Rollen bündeln wiederkehrende Arbeit in vorhersehbare Formen für Operatoren, Prüfende, Eigentümer und spätere projektspezifische Teams.
Eine benannte Bündelung hält Zuweisungen ruhig.
Anmeldungen, Freigaben, Entzüge und sensible Änderungen sollen alle eine Spur hinterlassen, die später geprüft werden kann.
Hilfreich für Vorfälle und laufende Governance.