Nicolas Cantu
3b3e1e67de
- Add services/claw-harness-api/upstream → chinanpc/claude-code-rust (shallow) - Document claw submodule and MIT Rust harness in service-claw-harness + feature doc - agent-regex-search: map design principles to rg implementation vs indexed search - SSO gateway: no user/project account storage; product DBs own identity context
41 lines
2.8 KiB
Markdown
41 lines
2.8 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**) et le **proxy** vers les micro-services du monorepo avec leurs **jetons techniques**.
|
||
|
||
- 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 l’amont avec le **Bearer de service** ou la **clé API** attendue par chaque cible.
|
||
|
||
Les appels **machine à machine** sans contexte utilisateur (scripts, `ia_dev`) restent possibles **en direct** vers chaque service, comme avant : la passerelle est une **option** pour les parcours « utilisateur authentifié par docv ».
|
||
|
||
## 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`. Les variables d’environnement sont les mêmes que pour le reste de la plateforme ([`config/services.local.env.example`](../../config/services.local.env.example)).
|
||
|
||
## 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)
|
||
- [services/smart-ide-sso-gateway/README.md](../../services/smart-ide-sso-gateway/README.md)
|