4nk/smart_ide
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
smart_ide/docs/features/sso-gateway-service.md
Nicolas Cantu 940cf59178 Share upstream definitions in @4nk/smart-ide-upstreams, systemd user units 
- Add packages/smart-ide-upstreams (versioned dist) for resolveUpstream + listUpstreamKeys
- Wire smart-ide-global-api and smart-ide-sso-gateway via file: dependency
- Add systemd user unit templates and install-smart-ide-gateway-systemd-user.sh (SSO After/Requires global API)
- Update docs and VERSION 0.0.3
2026-04-04 15:37:58 +02:00

3.7 KiB
Raw Permalink Blame History

Passerelle SSO — accès utilisateur aux API smart_ide

Rôle

Le service smart-ide-sso-gateway (services/smart-ide-sso-gateway/) centralise la validation OIDC (jeton utilisateur émis par docv / Enso) puis délègue le proxy HTTP au service smart-ide-global-api (services/smart-ide-global-api/), qui applique les jetons techniques vers chaque micro-service.

  • Le navigateur ou un BFF présente un access_token utilisateur (Authorization: Bearer).
  • La passerelle vérifie la signature (JWKS), iss, éventuellement aud, puis appelle smart-ide-global-api avec GLOBAL_API_INTERNAL_TOKEN et propage X-OIDC-Sub / X-OIDC-Email pour les journaux et règles amont.

Les micro-services n’implémentent pas le SSO ; ils écoutent en local (127.0.0.1) avec authentification par jeton de service. Les appels machine à machine sans contexte utilisateur (scripts, ia_dev) peuvent toujours cibler directement un micro-service ou, pour un seul point d’entrée technique, smart-ide-global-api avec le Bearer interne.

Lien avec docv / Enso

Le flux authorization code + PKCE et le rôle d’IdP restent décrits dans sso-docv-enso.md. La passerelle ne remplace pas docv : elle consomme les access_token déjà obtenus par le front ou un back de confiance.

Amonts proxy

Les clés exposées par GET /v1/upstreams et utilisées dans /proxy/<clé>/... sont : orchestrator, repos_devtools, ia_dev_gateway, anythingllm_devtools, tools_bridge, langextract, regex_search, claw_proxy, local_office. La résolution des URL et jetons par clé est implémentée dans smart-ide-global-api ; fichier d’exemple agrégé : config/services.local.env.example.

Journaux : .logs/sso-gateway/access.log (passerelle) et .logs/global-api/access.log (agrégateur), lignes JSON par requête (hors GET /health pour l’API globale ; hors GET /health et OPTIONS pour le SSO).

En-têtes vers l’amont

En plus de l’authentification de service, la passerelle peut envoyer :

  • X-OIDC-Sub — claim sub du JWT utilisateur ;
  • X-OIDC-Email — claim email si présent.

Les services amont peuvent s’en servir pour du journal ou des règles fines ; la politique d’autorisation métier reste de leur responsabilité.

Comptes, projets et bases métier

La passerelle ne conserve pas de comptes utilisateurs, de profils projet, ni de quotas métier : elle ne fait que vérifier le JWT OIDC et relayer vers smart-ide-global-api, qui applique les jetons techniques et proxifie vers chaque micro-service.

Les comptes, droits par projet, abonnements, historiques et toute persistance métier liée à l’identité restent dans les bases des applications (ex. docv, Enso, autres produits) et dans leurs schémas de données — pas dans smart-ide-sso-gateway. Le découpage par projet côté IDE et chemins de déploiement est décrit sous projects/<id>/conf.json — repo/projects-directory.md.

Les services amont qui reçoivent X-OIDC-Sub / X-OIDC-Email sont responsables de résoudre l’utilisateur vers un contexte projet via leurs API et bases.

Documentation détaillée