SSO, SCIM & sources d'identité (attribution ferme)

Édition

Les sources d’annuaire (LDAP, Okta/Entra et IdP d’agents/charges), le cycle de vie des identités gérées et le serveur SCIM entrant nécessitent les extensions Business/Enterprise. Community conserve l’ingestion générique, le catalogue de ressources, les constats de sécurité, l’Access Map, l’inventaire des identités, SSO avec un IdP, les rôles et associations locaux, les politiques et approbations. Les panneaux et commandes CLI payants sont masqués ; leurs routes API publiées renvoient HTTP 501. Activer un module n’ajoute pas son implémentation Business.

L’identité est la dépendance dure sous l’ensemble de l’access map : l’audit natif attribue un accès à un identifiant (credential), et seul un roster d’identité peut lier ce credential à un agent ou une personne. Cette page câble les trois surfaces d’identité : le login SSO de la console, le provisioning SCIM dans le control plane, et les sources de roster (LDAP, Okta, Entra ID) qui rendent l’attribution attributed au lieu d’approximate.

1. SSO console (OIDC / SAML)

Le login fédéré est servi via le seam de fédération du moteur. La posture est honnête par construction :

• Les points de terminaison du flux de login existent dans chaque build, et le moteur conserve côté serveur chaque valeur de flux porteuse de secret — le state CSRF, le nonce OIDC, le verifier PKCE (seul le challenge S256 part vers le fournisseur). Authorization Code + PKCE est toujours actif.
• La connexion OIDC/SAML avec un seul IdP est disponible dans toutes les éditions, Community comprise. Configurez-la dans les paramètres SSO gérés de la console. En l’absence de configuration gérée, le moteur utilise les variables au démarrage (OLIVARES_SSO_PROTOCOL, OLIVARES_OIDC_* ou OLIVARES_SAML_*). Sans fournisseur configuré, NoFederation retourne 501 sso_not_configured : il manque une configuration, le protocole n’est pas réservé aux éditions commerciales.
• L’URI de redirect/ACS que votre IdP doit porter est exacte (…/v1/auth/federation/callback sur l’origine de votre console — correspondance exacte RFC 9700, sans astuces de préfixe).

L’onglet Identity & NHI → SSO & SCIM de la console documente la configuration en direct, vérifie l’URI de redirect de votre IdP par rapport à la valeur exacte attendue, et affiche l’état de la connexion — et là où le backend d’un panneau est un contrat déclaré pas encore en service, il indique « backend pending » plutôt que de rendre des données fabriquées :

2. Provisioning SCIM (entrant) — Business

Le serveur SCIM entrant est une capacité Business (Identity & Scale). Un serveur Community monte les mêmes URL, authentifie le jeton, puis répond HTTP 501 au format d’erreur SCIM en nommant Business ; rien n’est lu ni écrit. Dans Community, vous retirez une personne de l’organisation dans la console (Personnes) ou avec DELETE /v1/members/{id}.

Avec Business, le control plane est un fournisseur de service SCIM 2.0 (RFC 7644) standard à :

/v1/scim/v2/Users
/v1/scim/v2/Groups

• Auth : un jeton d’API admin/owner lié au tenant sur l’intégration SCIM — le même modèle de jeton opaque que le reste de l’API, pas de type de secret SCIM distinct. Les URL sont toujours montées (non conditionnées par feature) ; Community y répond 501.
• Users provisionne et déprovisionne les identités. Les changements dépendent de la livraison et du traitement réussi de la requête SCIM ; vérifiez sa réponse et les accès concernés, sans considérer un événement RH comme la preuve d’une révocation terminée. SCIM ne supprime pas les comptes du système d’exploitation.
• Groups porte les données de référence identité-vers-groupe. Chaque groupe peut mapper vers un rôle du control plane via mapped_role — et ce mapping est détenu par l’opérateur : il est défini côté control plane et audité (scim.group.role.map) ; un push d’IdP n’escalade jamais silencieusement un rôle. Les membres inconnus dans un groupe poussé sont ignorés et audités, non inventés.

3. Sources de roster : LDAP, Okta, Entra ID — Business/Enterprise

Les sources de roster alimentent l’inventaire d’identité du module VI et — c’est là le point — donnent au module III les liaisons qui font monter l’attribution en gamme :

{
  "sources": [
    {
      "name": "corp-ldap",
      "kind": "ldap",
      "tenant": "<tenant-id>",
      "config": {
        "url": "ldaps://ldap.corp.example:636",
        "bind_dn": "cn=olivares-ro,ou=svc,dc=corp,dc=example",
        "bind_password": "<reference>",
        "base_dn": "dc=corp,dc=example"
      }
    },
    {
      "name": "okta",
      "kind": "idp",
      "tenant": "<tenant-id>",
      "config": { "provider": "okta", "base_url": "https://corp.okta.com", "api_token": "<reference>" }
    }
  ]
}

Options LDAP clés (issues du descripteur livré) : user_filter / group_filter, privileged_group_dns (groupes dont l’appartenance est elle-même un signal d’accès privilégié), nhi_dn_suffix (quel sous-arbre contient les identités non humaines), start_tls, page_size. Le kind idp prend provider: okta (avec api_token) ou provider: entra (avec tenant_id / client_id / client_secret) ; okta et entra fonctionnent aussi directement comme kind.

Comment cela fait monter l’attribution en gamme — précisément

Une source de roster enregistre des identités (par external id) et, là où l’annuaire les déclare, des grants autorisés. Lorsque l’origine d’une arête observée correspond à une identité de roster non partagée, le module III lie l’accès à cette identité et la confiance de l’arête est élevée à attributed. Les identités que plusieurs charges de travail partagent restent honnêtement approximate — le roster ne peut pas dé-partager un credential ; seule l’émission d’une identité par agent le peut (le pont vers la gouvernance).

Des kinds dédiés d’identité d’agent et d’identité de charge de travail (les sources de fédération d’agents — Entra Agent ID, AgentCore, SPIFFE et leurs pairs) constituent le signal ferme par agent ; les rosters de groupe/annuaire affinent les personnes et les comptes de service.

Limites honnêtes

• Community inclut le SSO avec un seul IdP. Le routage entre plusieurs IdP et le mappage des groupes lors de la connexion sont fournis par le module privé d’identité correspondant. La gestion générale des utilisateurs, groupes et permissions reste disponible dans Community.
• Un roster ne peut pas réparer un credential partagé. Il peut seulement vous dire, honnêtement, que le credential est partagé.
• SCIM est du provisioning entrant — le control plane ne pousse pas d’identités vers votre IdP, et le récepteur de Security-Event-Token est une surface entrante, pas un webhook sortant.

Voir aussi

• Connecter une source — pourquoi l’identité est la dépendance dure.
• Gouverner et approuver — rôles, RBAC et ce qu’un mapped_role accorde.
• Connecteurs & paliers de couverture — la liste complète des sources d’identité (Vault, Infisical, Keycloak, SPIFFE, les kinds de fédération d’identité d’agent).