Obexal Docs

Docs/Annuaire et provisioning/SCIM entrant (serveur)

SCIM entrant (serveur)

Provisionner et déprovisionner les comptes Obexal depuis votre IdP d'entreprise ou votre SIRH via l'endpoint SCIM 2.0 Users.

Obexal expose un serveur SCIM 2.0 (RFC 7643/7644) pour qu'un IdP d'entreprise (Okta, Microsoft Entra ID...) ou un SIRH pilote le cycle de vie des comptes de votre organisation : créer les utilisateurs, mettre à jour leur profil, et les désactiver à l'offboarding.

Ce que le serveur SCIM prend en charge

L'URL de base est https://accounts.obexal.com/scim/v2 (votre domaine personnalisé remplace le domaine par défaut). L'implémentation est volontairement un sous-ensemble bien supporté :

  • Users uniquement : il n'y a ni ressource /Groups ni endpoint bulk. C'est une configuration SCIM valide et courante ; gérez les groupes dans la console ou via l'API d'administration.
  • Le filtrage couvre les deux formes que les provisioners utilisent réellement : userName eq "..." et externalId eq "..." (200 résultats max par page).
  • GET /scim/v2/ServiceProviderConfig annonce exactement cela : patch supporté, bulk, sort, etag et changePassword non supportés.

Requêtes et réponses utilisent application/scim+json ; les erreurs arrivent dans l'enveloppe d'erreur SCIM standard, avec un 401 pour un jeton absent ou invalide.

Créer un jeton de provisioning

L'authentification repose sur un jeton bearer par organisation. Un admin le crée dans la console ou via l'API (permission de gestion du tenant) :

curl -sS -X POST https://accounts.obexal.com/v1/admin/scim/tokens \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"Provisioning Okta"}'
# 201 -> {"id":"...","name":"Provisioning Okta","token":"<secret>","scimBaseUrl":"https://accounts.obexal.com/scim/v2"}

Le secret n'est renvoyé qu'une seule fois ; seul son hachage SHA-256 est stocké. Collez-le dans le connecteur SCIM de votre IdP comme jeton bearer. GET /v1/admin/scim/tokens liste les jetons avec lastUsedAt (mis à jour à chaque usage, pour repérer les connecteurs morts), et DELETE /v1/admin/scim/tokens/{id} en révoque un immédiatement. Création et révocation sont auditées (scim.token.created, scim.token.revoked). Chaque appel SCIM est borné à l'organisation du jeton : l'accès inter-tenant est impossible par construction.

Opérations supportées

Méthode et cheminEffet
GET /scim/v2/UsersListe, ou résolution d'un filtre (userName / externalId)
POST /scim/v2/UsersCrée un utilisateur (201 ; 409 si l'e-mail ou l'externalId existe déjà)
GET /scim/v2/Users/{id}Lit un utilisateur
PUT /scim/v2/Users/{id}Remplacement : applique active et les champs de profil présents dans le corps
PATCH /scim/v2/Users/{id}Mise à jour partielle d'active et des champs de profil (styles PatchOp Okta et Entra)
DELETE /scim/v2/Users/{id}Désactive le compte (204) ; c'est une désactivation, pas un effacement

Correspondance des attributs

Attribut SCIMChamp Obexal
userNameAdresse e-mail (en minuscules ; l'identifiant du compte)
externalIdL'identifiant stable de votre IdP, stocké et renvoyé pour la corrélation
activetrue = statut active, false = statut deactivated
name.givenName / name.familyNamePrénom et nom
displayName (ou name.formatted à la création)Nom d'affichage
titlePoste
urn:...:extension:enterprise:2.0:User departmentDépartement
localeLangue préférée
emailsDérivé de userName (un seul e-mail principal)

Créer un utilisateur

curl -sS -X POST https://accounts.obexal.com/scim/v2/Users \
  -H "Authorization: Bearer $SCIM_TOKEN" \
  -H 'Content-Type: application/scim+json' \
  -d '{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User",
                "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
    "userName": "alice@example.eu",
    "externalId": "00u1abcd",
    "active": true,
    "name": {"givenName": "Alice", "familyName": "Martin"},
    "title": "DAF",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {"department": "Finance"},
    "emails": [{"value": "alice@example.eu", "primary": true}]
  }'
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User",
              "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
  "id": "u_7f3a9c",
  "userName": "alice@example.eu",
  "externalId": "00u1abcd",
  "active": true,
  "name": {"givenName": "Alice", "familyName": "Martin", "formatted": "Alice Martin"},
  "title": "DAF",
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {"department": "Finance"},
  "emails": [{"value": "alice@example.eu", "primary": true}],
  "meta": {
    "resourceType": "User",
    "location": "https://accounts.obexal.com/scim/v2/Users/u_7f3a9c",
    "created": "2026-07-02T09:30:00Z",
    "lastModified": "2026-07-02T09:30:00Z"
  }
}
Note

Les comptes créés par SCIM démarrent avec email_verified=true : l'IdP d'entreprise se porte garant de l'identité, aucun e-mail de vérification n'est envoyé. L'utilisateur se connecte par SSO ou définit un mot de passe via la récupération de compte.

La désactivation est réellement appliquée

Passer active à false (via PATCH, PUT ou DELETE) est un vrai offboarding, pas un simple drapeau : le statut du compte devient deactivated, les sessions existantes cessent de fonctionner immédiatement (chaque requête authentifiée revérifie le statut), et toute nouvelle connexion est refusée. Repasser active à true restaure l'accès. Tous les changements de cycle de vie arrivent dans le journal d'audit : scim.user.provisioned, scim.user.deactivated, scim.user.reactivated, scim.user.profile_updated.

Pour pousser les comptes dans l'autre sens, d'Obexal vers vos applications SaaS, voir SCIM sortant.