Aller au contenu

Gerege Kiosk

Production · Couche 4 — Produit vertical · Dépôt : gerege-kiosk-mn · geregekiosk.mn

La plateforme unifiée des bornes en libre-service — fondée sur l'eID, augmentée par l'IA. Elle relie une borne installée dans un lieu public à la pièce d'identité électronique et permet au citoyen d'obtenir une attestation, de payer et d'imprimer un document sans faire la queue ni rencontrer un agent. Un service 24 h sur 24, indépendant des heures d'ouverture.

Propriété

La plateforme est détenue et exploitée par Gerege Kiosk ХХК. Le code source se trouve dans un dépôt privé et repose sur le socle partagé open-gerege-core de Gerege Systems.

geregekiosk.mn sert désormais Gerege Nexus

Vérifié le 2026-08-07 : https://geregekiosk.mn/ renvoie un déploiement Gerege Nexus — le titre de la page est « Gerege Nexus » et la description est celle de Nexus. Le domaine possède son propre certificat valide et se trouve sur 38.180.243.183.

Le comportement de gerege-kiosk-mn décrit sur cette page peut donc ne plus correspondre à ce que sert le domaine public. Vérifiez la version qui tourne sur un terminal par rapport à ce déploiement.

L'idée maîtresse — application mince, socle épais

Le backend Go de Kiosk tient dans un seul fichier. Authentification, RBAC, passerelle API, pipeline IA, eID/SSO : toutes les capacités de base résident dans le module github.com/gerege-systems/open-gerege-core ; ce dépôt le récupère par version et le démarre sous son propre nom :

func main() {
    server.ServiceName = "gerege-kiosk"

    app, err := server.NewApp()
    if err != nil { /* … */ }

    // Les routes propres à l'application s'ajoutent ici :
    //   app.Router().Route("/api/xxx", xxx.Routes(app.Pool()))

    if err := app.Run(); err != nil { /* … */ }
}

C'est la réponse à la dette technique de synchronisation des forks évoquée sur la page Template Platform : auparavant, le code de base était copié dans chaque dépôt et chaque amélioration devait être reportée à la main. Kiosk est désormais un consommateur versionné de open-gerege-core : les correctifs de sécurité se diffusent depuis un point unique et la mise à jour tient en une commande, go get open-gerege-core@latest.

Couche Où elle vit Qui la possède
Backend de base (authentification, RBAC, IA, passerelle, migrations) module open-gerege-core Gerege Systems
Point de démarrage, marque, configuration gerege-kiosk-mn/backend Gerege Kiosk ХХК
BFF frontend, UI gerege-kiosk-mn/frontend Gerege Kiosk ХХК
Déploiement, vhost edge gerege-kiosk-mn/deploy Gerege Kiosk ХХК

Structure

gerege-kiosk-mn/
├── backend/     # Go · consommateur mince de open-gerege-core (cmd/api/main.go)
├── frontend/    # Next.js 15 BFF — Node 20, TanStack Query, mn/en/zh/ru
├── ios/         # Client SwiftUI de référence (ne dialogue que via le BFF)
└── deploy/      # compose, vhost edge nginx, certificat TLS de la base interne

Le backend de base suit la Clean Architecture — handler → usecase → repository → domain, sans back-import et sans ORM (SQL écrit à la main sur pgx).

Authentification — uniquement Gerege SSO

L'écran de connexion ne comporte qu'un seul bouton : Se connecter avec Gerege SSO. Ni mot de passe, ni inscription par e-mail/OTP, ni parcours eID direct.

graph LR
    C["Citoyen / borne"] --> W["geregekiosk.mn<br/>Next.js BFF"]
    W --> A["API Kiosk"]
    A --> S["sso.gerege.mn<br/>Gerege SSO"]
    S --> E["eID Mongolia"]
    S -.->|"proxy eID"| A
  • Parcours RP OIDC — /api/auth/sso/start → sso.gerege.mn → /sso/callback. Sur mobile, un parcours distinct de client public avec PKCE (native) est prévu.
  • Session — JWT access + refresh, le refresh étant rotatif ; la déconnexion invalide le refresh et place l'access sur une deny-list.
  • Le jeton n'atteint pas le navigateur — il reste dans un cookie httpOnly et tout passe par le BFF.

Pourquoi Kiosk n'est-il pas lui-même RP eID ?

Selon la règle de frontière n° 2, les applications des couches 3–4 n'accèdent jamais directement à l'eID. Kiosk ne détient pas d'identifiants de RP eID : tous les échanges avec l'eID passent par Gerege SSO. Les identifiants restent ainsi en un seul endroit et la piste d'audit n'est pas rompue.

Profil PKI eID — par le proxy

Le tableau PKI du citoyen connecté est récupéré via le proxy eID du SSO. Kiosk appelle avec l'access token de l'utilisateur, et le SSO obtient les données au moyen de ses propres identifiants eID.

Quoi Où cela s'affiche
Synthèse /me/eid/id
Certificats et statut /me/eid/certificates
Appareils associés /me/eid/devices
Historique d'authentification/signature /me/eid/logs
Organisations rattachées et signataires habilités /me/organizations

Le cas où le proxy est désactivé (service eid-proxy inactif sur le SSO) ou le jeton devenu invalide est traité à part par l'interface — et non renvoyé en 5xx.

Fournisseur OIDC à part entière

Kiosk peut être à la fois relying party du SSO et fournisseur d'identité lui-même. Lorsque OAUTH_ISSUER et la clé d'état sont configurés, son propre fournisseur OAuth2/OIDC en Go s'active (sans Ory Hydra) :

  • écrans login · consent · logout sous /oauth,
  • enregistrement des RP dans la table oauth_clients, rotation des secrets,
  • consentement contourné pour les clients de première partie, et mémorisé,
  • discovery, userinfo, id_token — la clé de signature est stockée chiffrée.

Les petites applications qui entourent Kiosk peuvent ainsi proposer « Sign in with Gerege Kiosk ».

La surface tournée vers le citoyen

Section Ce qu'elle fait
/me/dashboard Tableau de bord personnel
/me/services · /me/applications Catalogue de services, demandes et suivi
/me/references Attestations
/me/notifications Notifications
/me/payments Paiements
/me/appointments Prise de rendez-vous
/me/organizations Organisations, affiliations, droits
/me/eid/sign Signature électronique d'un document
/me/integrations Connexions tierces et Gerege Space
/me/ai · /me/translate Assistant IA, traduction en direct

Pour créer ou rechercher une organisation, la vérification auprès du registre de l'État se fait via Gerege Verify. Les données d'organisation sont protégées par la RLS de Postgres pour chaque utilisateur.

Registre unifié des services

Composant R1 de Ring System — le passeport de service et la gestion des preuves :

  • catalogue des services, versions, publication/archivage,
  • événements de vie (life events) — regroupement des services selon la situation du citoyen,
  • preuves (evidences) et tableau once-only, qui mesure l'application du principe consistant à ne pas redemander une pièce déjà fournie.

Les droits sont à deux niveaux : registry.view (lecture) et registry.manage (écriture).

API Gateway

Un catalogue de services piloté depuis l'admin : services · routes · consumers · clés d'API · policy, plus la télémétrie des requêtes (overview + logs).

Périmètre actuel

La passerelle constitue pour l'instant une couche de pilotage et de télémétrie. L'application effective des route/policy configurés en véritable reverse-proxy (rate-limit et quotas au niveau du consumer) est prévue.

Signature électronique et sign relay

  • PAdES — signature de PDF côté serveur via l'interface /v3 d'eID Mongolia, avec un certificat Document-Signer permanent (fail-closed en production).
  • Sign relay — une passerelle permettant à des RP tiers de signer au travers des identifiants eID de la plateforme. Cette route ne passe pas par le BFF web mais va directement de l'edge à l'API (port loopback). Le résultat est notifié par webhook.

Pour la différence entre la signature personnelle du citoyen avec PIN2 et la signature système Document-Signer, voir la page G-Sign.

Assistant IA (Gemini)

Un pipeline bâti sur un client REST sans SDK :

Capacité Détail
Chat Messages texte et vocaux, function calling
STT Parole → texte
TTS Texte → parole (PCM→WAV)
Traduction Traduction en flux continu

System prompt à trois couches : garde-fous codés en dur, plus un périmètre et des consignes réglés par l'administrateur via la base. La couche garde-fous n'est jamais configurable.

L'outil search_knowledge ancre la réponse dans les données réelles de la base de connaissances. La recherche est sémantique — embedding Gemini + proximité cosinus sur pgvector, avec repli sur ILIKE en cas d'échec.

Si Gemini est momentanément indisponible, le chat ne renvoie pas un 5xx mais une réponse dégradée (degraded: true) dans la langue de l'utilisateur. Les routes /ai/* sont limitées à environ 20 requêtes par minute et par IP.

Intégrations et stockage

  • Connexions OAuth tierces — Google Drive · Google Meet · Dropbox. Les jetons sont stockés chiffrés en AES-256-GCM ; si les identifiants ne sont pas configurés, la carte correspondante apparaît inactive avec la mention « Bientôt ».
  • Gerege Space — le stockage SFTP propre à l'application, avec un quota par utilisateur. La host key SFTP est vérifiée (obligatoire en production — sinon fail-closed).

Droits, administration, audit

  • RBAC — rôles dynamiques et catalogue de permissions, modèle à quatre niveaux (superadmin → admin → manager → user).
  • Super admin — compte distinct, parcours d'onboarding avec MFA (allow-list d'invitations → Google → eID → OTP par e-mail → TOTP + codes de secours). Stocké dans sa propre table, de sorte qu'une même personne peut être à la fois admin eID et super admin.
  • Audit log — chaîné par hachage, en ajout seul ; lecture par l'admin et endpoint de vérification d'intégrité.
  • Security events — ingestion et tableau de bord de surveillance.
  • Apparence du site — accent / police / densité / thème réglables par l'administrateur, avec surcharge par utilisateur.

Sécurité

Contrôle Mise en œuvre
Isolation des données RLS Postgres (ENABLE + FORCE) ; l'api se connecte avec un rôle non superuser, et l'application effective est vérifiée au démarrage
Session Cookie httpOnly, le jeton n'atteint jamais le JS client
CSRF Double protection — en-tête dédié + vérification d'origine (sur toutes les routes mutantes du BFF)
En-têtes CSP · HSTS · COOP/COEP/CORP, allow-list CORS
Limitation de débit Connexion ~5 requêtes/min (corps plafonné à 4 KiB), application 50 r/s, /ai/* ~20/min
Connexion à la base En production sslmode=verify-full — TLS avec une CA interne
Endpoints d'observation En production, /metrics et /swagger protégés par bearer token
Confiance au proxy Si TRUSTED_PROXIES n'est pas défini, X-Forwarded-For n'est pas jugé fiable (protège contre la falsification du rate-limit et de l'audit)

Pour les exigences communes de l'écosystème, voir la page Sécurité.

Observabilité

Traces OpenTelemetry + métriques Prometheus + logs structurés Zap. Dans la télémétrie, le service apparaît sous le nom gerege-kiosk.

Déploiement

Stack Docker Compose : db (Postgres 16 + pgvector) · redis · migrate (à usage unique) · api · web. Le navigateur n'atteint que web ; api/db/redis restent sur le réseau interne et n'ouvrent aucun port public.

Trois décisions de déploiement méritent l'attention :

  1. La migration est une étape distincte, et non une partie de up -d. Auparavant, chaque nouvelle exécution de migrate recréait api et web, et même un commit ne touchant pas au code provoquait un 502 d'une seconde.
  2. Si rien n'a changé, ne rien faire du tout. La construction Docker n'étant pas reproductible, un même code produit un nouvel ID d'image. Aussi, si HEAD n'a pas bougé, le déploiement est entièrement sauté.
  3. Les services de données ne sont pas reconstruits à chaque déploiement — recréer db coupe toutes les connexions actives à la base.

Le vhost de l'edge nginx appartient à ce dépôt : à chaque déploiement il est installé dans conf.d, validé par nginx -t puis appliqué par un reload ; si le test échoue, la configuration précédente est restaurée. C'est le même modèle que pour docs.gerege.mn, le Developer Portal et la Template Platform.

Langues

Interface et documentation en quatre langues : Монгол · English · 中文 · Русский. L'exhaustivité des dictionnaires du frontend est imposée par un test — si une clé manque dans une langue, la CI échoue.

État actuel

Production En service sur geregekiosk.mn. Les capacités de la plateforme de base sont entièrement héritées ; les parcours propres au métier des bornes continuent de s'ajouter.

Prochaines étapes : application effective des règles par la passerelle, réponses de chat en streaming (SSE), CSP fondée sur des nonces, sauvegarde automatique de la base avec test de restauration, environnement de staging.

Pages liées