Ronova Dengronova.dev
AccèsFR

Répertoire central

Ronova ID

Une seule couche d'identité pour les sites, applications et outils internes appartenant à Ronova.

L'authentification reste basée sur la redirection, les sessions restent limitées par application et les permissions restent explicites au lieu de se répandre partout.

Ouvrir la vue du compteExaminer la gouvernance admin

Répertoire central

Choisir une surface

Chaque surface partage la même fondation d'identité, mais chacune répond à une question différente.

FondationVue centraleCouche d'identitéMontre comment Ronova ID relie les sites, applications et consoles internes appartenant à Ronova.CompteSurface de compte personnelleAutonomieConsulte les données de profil, les sessions actives, l'historique de redirection et la posture personnelle de récupération.GouvernanceContrôles administratifsAccès gouvernéEnregistre les clients, attribue les rôles, inspecte les traces d'audit et encadre les opérations sensibles.

Accès direct

Accès par passkey

Ronova ID se connecte maintenant avec des passkeys vérifiées par l'utilisateur. Le bootstrap temporaire reste seulement pour inscrire la première passkey owner depuis une session admin privée existante.

Ronova ID est émis pour les projets exploités par Ronova par invitation, migration ou demande examinée via l'assistance/contact projet. Il n'y a pas de formulaire d'inscription publique en libre-service ici.

Le bootstrap sert uniquement à une session admin privée existante qui inscrit la première passkey owner.

Les sous-domaines Ronova partagent la session ID same-site; les autres clients inscrits utilisent toujours les codes de redirection.

Fondation

Ce que couvre la fondation

Ronova ID est la fondation d'identité, pas un badge de connexion décoratif. C'est là que la confiance commence, se resserre et se vérifie ensuite.

Vue centrale de l'identité

Une seule source de profil, une seule trace de propriété et un seul endroit pour comprendre quelle surface opérée par Ronova demande une identité.

Utile pour les sites publics, les applications expérimentales et les consoles privées.

Sessions limitées par application

Chaque application conserve sa propre enveloppe de session afin qu'une connexion sur un outil n'autorise pas silencieusement tous les autres.

Courte durée pour le travail élevé, persistance plus calme pour les vues à faible risque.

Authentification par redirection

L'authentification passe par des redirections explicites avec une destination de retour nommée et une raison enregistrée.

Le transfert reste lisible au lieu de disparaître dans un état en arrière-plan.

Parcours

Parcours de redirection

Le chemin de redirection doit rester explicite depuis la première demande jusqu'au retour de la personne dans l'application.

  1. 01

    Le client demande l'identité

    Une application envoie la personne vers Ronova ID avec son nom de client, la portée demandée et la destination de retour.

  2. 02

    La personne confirme le transfert

    Ronova ID montre quel client a demandé, ce qu'il veut et vers quoi la personne sera renvoyée après approbation.

  3. 03

    La session limitée est créée

    Seule la portée demandée est émise, et la session obtenue reste liée à ce client précis.

  4. 04

    L'application récupère la personne

    L'application reprend avec le contexte d'identité accordé tandis que la chaîne de demande reste visible pour une revue future.

Catalogue des clients

Catalogue des applications et des clients

La même couche d'identité peut servir des surfaces très différentes sans prétendre qu'elles ont toutes besoin du même accès.

Surfaces publiques de ronova.dev

La vue d'identité, l'orientation du support et les entrées de compte partagent une même frontière de confiance sans se fondre dans une session unique trop large.

Peu de privilèges, beaucoup de clarté.

Clients de compte sur gekka-harae.com

La connexion côté joueur, la présence de profil, les sauvegardes et l'assistance de compte peuvent demander l'identité nécessaire sans hériter d'un pouvoir administratif.

Accès centré sur l'utilisateur.

Console interne d'exploitation

La modération, le tri du support, la gouvernance de publication et la recherche d'audit restent des clients distincts avec des contrôles plus forts.

Portée opérationnelle à forte confiance.

Gouvernance

Concepts de permissions, de rôles et d'audit

L'identité ne consiste pas seulement à entrer. Elle consiste aussi à prouver qui a demandé, qui a approuvé et ce qui a changé ensuite.

Les permissions restent explicites

Les permissions restent lisibles plutôt que vagues. Un client doit demander des capacités comme lire le profil, ouvrir un contexte de support ou administrer des clients.

Des permissions nommées rendent l'approbation compréhensible.

Les rôles regroupent le travail

Les rôles regroupent le travail récurrent en formes prévisibles pour les opérateurs, les relecteurs, les propriétaires et les futures équipes de projet.

L'attribution devient plus calme quand l'ensemble porte un nom.

L'audit reste attaché

Les connexions, approbations, révocations et mutations sensibles doivent toutes laisser une trace pouvant être revue plus tard.

Utile pour les incidents et pour la gouvernance courante.