Aller au contenu

Architecture en couches

L'écosystème se compose de cinq couches. La couche inférieure sert la couche supérieure ; la couche supérieure ignore la structure interne de celle du dessous et ne dialogue avec elle qu'à travers son contrat.

COUCHE 4 — PRODUITS VERTICAUX (vertical)
    ring.dgov.mn          Ring System — réingénierie des processus
    hurdan.dgov.mn        Plateforme « Khurdan » — délivrance et suivi des services
    developer.gerege.mn   Developer Portal (version dgov également)
    wallet.gerege.mn      Gerege Wallet — portefeuille numérique du citoyen

COUCHE 3 — SOCLE DE PLATEFORME
  -- 2e génération : Nexus — monolithe modulaire, app store
    nexus.gerege.mn       Gerege Nexus — upstream, 8 modules
    eduge.mn              Eduge.mn — fork de marque sectorielle
    (domaine à venir)     Gerege SSO — fork centré sur la connexion
  -- 1re génération : Template — un fork par dépôt
    template.gerege.mn    Gerege Template Platform
    template.dgov.mn      Government Template Platform V3.0 (+ portage Node.js)
    gerege.mn             Gerege Platform (fournisseur SSO à part entière)
    → Clean Architecture Go + Next.js BFF + pipeline Gemini AI

COUCHE 2 — AUTHENTIFICATION / SSO (fournisseur OIDC)
    sso.gerege.mn   Gerege SSO          sso.dgov.mn      Government SSO
    dan.gerege.mn   DAN Gateway         gsign.gerege.mn  G-Sign
    → code OAuth2/OIDC Go maison (Hydra entièrement remplacé), une seule base
    → proxy eID : services eID autorisés vers les applications enregistrées

COUCHE 1 — NOYAU IDENTITÉ / PKI
    eID Mongolia (eid-platform-mn)
    server (Go) · web · admin · SDK iOS · SDK Android · macOS/Windows
    ECDSA à seuil 2-of-2 · double clé / double certificat (PIN1 auth / PIN2 signature)
    CA · OCSP · CRL · TSA

COUCHE 0 — ÉCHANGE DE DONNÉES
    X-Road instance MN — central server, security servers
    Service adjacent : xyp.gerege.mn (renseignements sur les personnes morales)

Couche 0 — Échange de données

De quoi s'agit-il : un canal normalisé d'échange de données entre organisations — X-Road (instance MN).

Rôle : les organisations membres appellent les services les unes des autres de manière authentifiée, signée et horodatée. Chaque security server représente son membre, et le central server signe puis diffuse la liste de confiance (globalconf).

Lien particulier : eID Mongolia assume le rôle d'autorité de certification (CA) pour X-Road — autrement dit, la couche 1 fournit à la couche 0 sa racine de confiance.

État : Partiel Le central server et les premiers security servers sont en service, la topologie est définie ; le déploiement à grande échelle se poursuit.

Couche 1 — Noyau identité / PKI

De quoi s'agit-il : eID Mongolia — la plateforme eID nationale (dans l'esprit Smart-ID / eIDAS).

Rôle : identifier les citoyens et les organisations, les authentifier et leur permettre d'apposer une signature juridiquement valable. Ainsi que tout le cycle de vie du certificat : émission (CA), vérification de validité (OCSP/CRL), horodatage (TSA).

Décisions clés :

  • ECDSA à seuil 2-of-2 — la clé privée de signature n'existe entièrement chez aucune des parties.
  • Double clé / double certificat — PIN1 → authentification, PIN2 → signature.
  • L'identifiant est civil_id ; l'ETSI ID vaut PNOMN-<civil_id> pour une personne physique et NTRMN-<...> pour une organisation.
  • KYC — via DAN, avec contrôle de vivacité par reconnaissance faciale.

Qui l'utilise : la couche 2 (SSO) directement ; les couches 3–4 via le SSO.

État : Production

Couche 2 — Authentification / SSO

De quoi s'agit-il : les fournisseurs OAuth2/OIDC — Gerege SSO (sso.gerege.mn) et Government SSO (sso.dgov.mn), ainsi que les services adjacents DAN Gateway et G-Sign.

Rôle — trois choses :

  1. Fournisseur d'identité — les RP peuvent proposer Sign in with Gerege. Authorization code + PKCE (S256), refresh token rotatif (avec détection de réutilisation), client_credentials.
  2. Proxy eID — les services eID autorisés ne sont transmis qu'aux applications enregistrées. L'application n'accède jamais directement à l'eID.
  3. Unique lieu d'enregistrement des applications — le client OAuth et son secret y sont créés et n'y vivent que là.

Sans Hydra

Ory Hydra était utilisé auparavant ; les mécanismes nécessaires ont été réécrits en code Go maison. La base Hydra distincte a été fusionnée avec la base principale. Trois choses ont baissé d'un coup : les dépendances externes, la complexité des migrations et le coût d'exploitation.

État : Production

Couche 3 — Socle de plateforme

Cette couche compte désormais deux générations. Toutes deux sont en production, et la transition de l'une à l'autre est en cours.

2e génération — Gerege Nexus Production

De quoi s'agit-il : une plateforme monolithe modulaire — les modules métier implémentent le contrat Go Module et se compilent dans un seul binaire ; les applications actives pour un locataire sont décidées par l'app store (app_installations) dans PostgreSQL.

Ce qui change : en 1re génération, un nouveau produit signifiait un fork du modèle. Sur Nexus, un nouveau produit est en général un nouveau module — ou, pour une marque, un fork de l'upstream, rafraîchi par fusion depuis celui-ci.

1re génération (Template) 2e génération (Nexus)
Nouveau produit Forker le modèle Écrire un module, ou forker pour une marque
Distribution Un déploiement par dépôt Par locataire, via l'app store
Circulation du code Paquets open-gerege-core · @gerege/ui-core Upstream → les forks fusionnent depuis lui
Appels entre modules HTTP Appels Go en processus

Forks actuels : nexus.gerege.mn (upstream, déploiement de référence) · eduge.mn (secteur éducatif) · Gerege SSO (centré sur la couche de connexion, pas encore de domaine).

Les huit modules livrés : Contacts · Products · Inventory · Billing & e-Barimt · Digital Documents · Developer Portal · signature électronique PDF (eID PIN2) · services publics (processus configurable, hiérarchie, SLA).

Nexus ne remplace pas la couche 2

Nexus embarque son propre fournisseur OAuth2/OIDC, mais celui-ci sert les locataires et les clients tiers de ce déploiement-là. À l'échelle de l'écosystème, la seule voie pour identifier un citoyen reste la couche 2 — Nexus non plus n'atteint jamais eID directement.

1re génération — Template Platform Production

De quoi s'agit-il : la Template Platform — un socle prêt pour la production destiné à construire des services numériques ; et Gerege Platform, sa variante étendue capable d'être elle-même fournisseur SSO.

Rôle : au lancement d'un nouveau service, tout ceci est disponible dès le premier jour :

  • authentification eID et Google, sessions (JWT access + rotation du refresh),
  • organisations et affiliations, protégées par RLS,
  • RBAC (superadmin → admin → manager → user), journal d'audit,
  • passerelle API (services / routes / consumers / clé d'API / policy + télémétrie),
  • pipeline IA (Gemini) — chat, STT/TTS, traduction, base de connaissances,
  • socle de sécurité strict (CSP/HSTS, allow-list CORS, rate limit, RLS),
  • observabilité (OpenTelemetry + Prometheus + logs structurés).

État : Production

Couche 4 — Produits verticaux

De quoi s'agit-il : les produits réels issus du Template.

Produit Objet État
Developer Portal Catalogue d'API, porte d'entrée de l'enregistrement d'applications Production
Gerege Wallet Portefeuille numérique du citoyen Partiel
Ring System Réingénierie des processus de services publics Partiel
Plateforme « Khurdan » Délivrance des services et supervision Production

Ring et Khurdan tournent sur la ligne gouvernementale.

Règle de dépendance

Tout le code de l'écosystème respecte le sens de dépendance suivant :

graph TD
    L4["Couche 4 — Produits verticaux"] --> L3["Couche 3 — Socle de plateforme"]
    L3 --> L2["Couche 2 — SSO / OIDC"]
    L2 --> L1["Couche 1 — eID / PKI"]
    L2 -.->|"renseignements"| L0["Couche 0 — X-Road"]
    L1 -.->|"rôle de CA"| L0

Règle : on ne saute pas une couche. Une application de la couche 4 n'accède jamais directement à l'eID : elle passe obligatoirement par le SSO. Cela maintient les identifiants en un seul endroit et préserve la continuité de la piste d'audit.

Le seul lien « vers le bas » autorisé est le rôle de CA de l'eID pour X-Road ; il constitue la racine de confiance et échappe donc à la règle des couches.