- New smart-ide-global-api (127.0.0.1:37149): internal bearer, upstream proxy, X-OIDC forward - SSO gateway calls global API with GLOBAL_API_INTERNAL_TOKEN; logs to .logs/sso-gateway/ - Aggregated config example, docs, VERSION 0.0.2, claw proxy local URL hint
3.5 KiB
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_tokenutilisateur (Authorization: Bearer). - La passerelle vérifie la signature (JWKS),
iss, éventuellementaud, puis appelle smart-ide-global-api avecGLOBAL_API_INTERNAL_TOKENet propageX-OIDC-Sub/X-OIDC-Emailpour 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— claimsubdu JWT utilisateur ;X-OIDC-Email— claimemailsi 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 les micro-services.
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.