SCIM sortant (provisioning)

Pousser le cycle de vie des comptes d'Obexal vers vos applications aval, avec déprovisionnement automatique à la suspension et échecs audités.

Le provisioning sortant est l'autre moitié de la gestion du cycle de vie : Obexal pousse la création, la réactivation et la désactivation des comptes vers les applications que vous utilisez. Sa valeur première est la sécurité : un utilisateur suspendu dans Obexal est désactivé partout, automatiquement. Cela fonctionne avec toute application exposant un endpoint SCIM 2.0.

Déclarer une cible

Une cible est un endpoint SCIM aval de votre organisation, géré sur /v1/admin/scim-targets (permission de gestion du tenant) :

curl -sS -X POST https://accounts.obexal.com/v1/admin/scim-targets \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d "{\"name\":\"Wiki\",\"baseUrl\":\"https://wiki.example.eu/scim/v2\",\"token\":\"$TARGET_TOKEN\",\"enabled\":true}"
# 200 -> {"id":"scimtgt_9f2e...","name":"Wiki","baseUrl":"https://wiki.example.eu/scim/v2","enabled":true,"hasToken":true}

GET liste les cibles (avec hasToken à la place du secret), PUT /v1/admin/scim-targets/{id} en met une à jour (un token vide conserve celui stocké), DELETE /v1/admin/scim-targets/{id} la supprime. Les appels sortants passent par un client HTTP anti-SSRF qui refuse les adresses internes et de bouclage, en plus de la règle HTTPS obligatoire.

Création idempotente et adoption de compte

Quand Obexal pousse un utilisateur vers une cible pour la première fois, il envoie POST /Users avec userName égal à l'e-mail, active: true et l'e-mail dans emails. L'id distant est mémorisé et pilote toutes les opérations futures pour cet utilisateur sur cette cible.

Si la cible répond 409 (le compte y existe déjà), Obexal adopte le compte existant : il le retrouve avec filter=userName eq "..." et conserve son id, mais seulement si la recherche renvoie exactement un résultat dont le userName correspond exactement à l'e-mail demandé (insensible à la casse). Toute ambiguïté est refusée, car un id mal adopté déprovisionnerait plus tard le compte de quelqu'un d'autre, ou laisserait le vrai compte actif à l'offboarding.

Déprovisionnement automatique

Quand un admin suspend un utilisateur, Obexal envoie automatiquement PATCH /Users/{id} avec active: false à chaque cible activée où l'utilisateur est connu. La réactivation le repousse (active: true, ou une création si la cible n'a jamais eu le compte). Aucune étape supplémentaire, aucune checklist manuelle : l'offboarding effectué dans Obexal se propage de lui-même.

L'envoi est volontairement best-effort : une cible en panne ne bloque jamais la suspension elle-même, qui a déjà réussi dans Obexal.

Rattraper un annuaire existant

Quand vous ajoutez une cible, les utilisateurs existants n'y sont pas encore. Déclenchez un rattrapage synchrone :

curl -sS -X POST https://accounts.obexal.com/v1/admin/scim-targets/<id>/sync \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN"
# 200 -> {"pushed": 42}

La synchronisation pousse chaque utilisateur actif de l'organisation vers cette cible (les suspendus sont ignorés) et renvoie le décompte. Une cible désactivée répond 409 target_disabled. Le rattrapage est plafonné à 10000 utilisateurs par exécution.

Les échecs sont audités, jamais silencieux

Un déprovisionnement qui échoue en silence donnerait une fausse impression de sécurité. Chaque issue, succès ou échec, est écrite dans le journal d'audit :

Les entrées d'échec portent le nom de la cible et la cause de l'erreur, jamais le jeton bearer. La livraison n'est pas durable au redémarrage du service : en cas de doute sur des envois manqués, relancez un sync sur la cible.

Limites

• Le sortant pousse le cycle de vie du compte (créer, activer, désactiver). Les changements de champs de profil ne sont pas propagés aux cibles.
• Users uniquement : pas de provisioning de groupes vers les applications aval.
• Pour le sens inverse (votre IdP provisionne Obexal), voir SCIM entrant.