Zentrales Verzeichnis

Ronova ID

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.

Kontoansicht öffnen Admin-Governance prüfen

Zentrales Verzeichnis

Oberfläche wählen

Jede Oberfläche teilt dieselbe Identitätsgrundlage, beantwortet aber eine andere Frage.

GrundlageZentraler ÜberblickIdentitätsschichtZeigt, wie Ronova ID Ronova-eigene Websites, Anwendungen und interne Konsolen zusammenhält.KontoPersönliche KontooberflächeSelbstverwaltungPrüft Profildaten, laufende Sitzungen, Redirect-Verlauf und die eigene Wiederherstellungsbasis.GovernanceAdministrative SteuerungGesteuerter ZugriffRegistriert Clients, weist Rollen zu, prüft Audit-Spuren und sperrt sensible Vorgänge ab.

Live-Zugriff

Passkey-Zugriff

Ronova ID meldet jetzt mit nutzerverifizierten Passkeys an. Der temporäre Bootstrap bleibt nur für eine bestehende private Admin-Sitzung, um den ersten Owner-Passkey einzurichten.

Ronova ID wird für Ronova-betriebene Projekte per Einladung, Migration oder geprüfter Anfrage über Projekt-Support/Kontakt vergeben. Hier gibt es kein öffentliches Self-Service-Registrierungsformular.

Ronova-Subdomains teilen die Same-Site-ID-Sitzung; andere registrierte Clients nutzen weiter Redirect-Codes.

Grundlage

Was die Grundlage abdeckt

Ronova ID ist die Identitätsgrundlage und kein dekoratives Login-Abzeichen. Hier beginnt Vertrauen, verengt sich und wird später wieder geprüft.

Zentraler Identitätsüberblick

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.

App-begrenzte Sitzungen

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.

Redirect-basierte Authentifizierung

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

Redirect-Reise

Der Redirect-Weg soll vom ersten Antrag bis zur Rückkehr in die App ausdrücklich sichtbar bleiben.

01
Client fordert Identität an
Eine App sendet die besuchende Person mit Client-Namen, gewünschtem Umfang und Rückziel an Ronova ID.
02
Person bestätigt die Übergabe
Ronova ID zeigt, welcher Client gefragt hat, was er möchte und wohin nach der Freigabe zurückgeführt wird.
03
Begrenzte Sitzung wird erstellt
Es wird nur der angeforderte Umfang ausgestellt, und die entstehende Sitzung ist an genau diesen Client gebunden.
04
App erhält die Person zurück
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

App- und Client-Katalog

Dieselbe Identitätsschicht kann sehr unterschiedliche Oberflächen bedienen, ohne so zu tun, als bräuchten alle denselben Zugriff.

Öffentliche Oberflächen von ronova.dev

Identitätsüberblick, Support-Routing und Kontoeinstiege teilen sich eine Vertrauensgrenze, ohne in einer einzigen breiten Sitzung zu verschwimmen.

Wenig Privileg, viel Klarheit.

gekka-harae.com-Kontoclients

Spielbezogene Anmeldung, Profilpräsenz, Speicherstände und Kontosupport können genau die benötigte Identität anfordern, ohne Admin-Macht zu erben.

Benutzerbezogener Zugriff.

Interne Betriebskonsole

Moderation, Support-Triage, Release-Governance und Audit-Suche bleiben getrennte Clients mit stärkeren Kontrollen.

Operativer Vertrauensbereich.

Governance

Konzepte für Berechtigungen, Rollen und Audit

Identität bedeutet nicht nur hereinzukommen. Sie bedeutet auch zu belegen, wer gefragt, wer genehmigt und was sich danach geändert hat.

Berechtigungen bleiben explizit

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 die Arbeit

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.

Audit bleibt angeheftet

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.