Nicolas Cantu
0af507143a
- 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
45 lines
3.5 KiB
Markdown
45 lines
3.5 KiB
Markdown
# 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](./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`](../../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 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](../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
|
||
|
||
- [API/sso-gateway-api.md](../API/sso-gateway-api.md)
|
||
- [API/global-api.md](../API/global-api.md)
|
||
- [services/smart-ide-sso-gateway/README.md](../../services/smart-ide-sso-gateway/README.md)
|
||
- [services/smart-ide-global-api/README.md](../../services/smart-ide-global-api/README.md)
|