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 vautPNOMN-<civil_id>pour une personne physique etNTRMN-<...>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 :
- 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. - Proxy eID — les services eID autorisés ne sont transmis qu'aux applications enregistrées. L'application n'accède jamais directement à l'eID.
- 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.