SSO, SCIM y fuentes de identidad (atribución firme)

Edición

Las fuentes de directorio (LDAP, Okta/Entra e IdP de agentes/cargas), el ciclo de vida de identidades gestionadas y el servidor SCIM entrante requieren los complementos Business/Enterprise. Community conserva la ingestión genérica, el catálogo de recursos, los hallazgos de seguridad, el Access Map, el inventario de identidades, SSO con un IdP, roles y bindings locales, políticas y aprobaciones. Oculta los paneles y comandos CLI de pago; sus rutas API publicadas devuelven HTTP 501. Activar un módulo no añade su implementación Business.

La identidad es la dependencia dura bajo todo el mapa de accesos: la auditoría nativa atribuye un acceso a una credencial, y solo un roster de identidad puede ligar esa credencial a un agente o persona. Esta página conecta las tres superficies de identidad: el login SSO de la consola, el aprovisionamiento SCIM hacia el control plane y las fuentes de roster (LDAP, Okta, Entra ID) que hacen la atribución attributed en lugar de approximate.

1. SSO de la consola (OIDC / SAML)

El login federado se sirve a través del seam de federación del motor. La postura es honesta por construcción:

• Los endpoints del flujo de login existen en todas las builds, y el motor mantiene del lado del servidor cada valor del flujo que porta secretos — el estado CSRF, el nonce OIDC, el verifier PKCE (solo el challenge S256 va al proveedor). Authorization Code + PKCE está siempre activo.
• El acceso OIDC/SAML con un único IdP está disponible en todas las ediciones, Community incluida. Se configura desde los ajustes SSO administrados de la consola. Si no hay configuración administrada, el motor usa las variables del arranque (OLIVARES_SSO_PROTOCOL, OLIVARES_OIDC_* o OLIVARES_SAML_*). Sin un proveedor configurado, NoFederation devuelve 501 sso_not_configured: indica que falta configuración, no que el protocolo sea exclusivo de las ediciones comerciales.
• La URI de redirect/ACS que tu IdP debe portar es exacta (…/v1/auth/federation/callback en el origen de tu consola — coincidencia exacta según RFC 9700, sin trucos de prefijo).

La pestaña Identity & NHI → SSO & SCIM de la consola documenta la configuración en vivo, comprueba la URI de redirect de tu IdP contra el valor exacto esperado y muestra el estado de la conexión — y allí donde el backend de un panel es un contrato declarado pero aún no operativo, dice “backend pending” en lugar de renderizar datos fabricados:

2. Aprovisionamiento SCIM (entrante) — Business

El servidor SCIM entrante es una capacidad Business (Identity & Scale). Un servidor Community monta las mismas URL, autentica el token y después responde HTTP 501 con el formato de error de SCIM, nombrando Business; no se lee ni se escribe nada. En Community quitas a una persona de la organización en la consola (Personas) o con DELETE /v1/members/{id}.

Con Business, el control plane es un proveedor de servicio SCIM 2.0 (RFC 7644) estándar en:

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

• Auth: un token de API de admin/owner ligado al tenant en la integración SCIM — el mismo modelo de token opaco que el resto de la API, sin un tipo de secreto SCIM aparte. Las URL están siempre montadas (no están detrás de un feature gate); Community responde 501 ahí.
• Users aprovisiona y desaprovisiona identidades. Los cambios dependen de la entrega y del procesamiento correcto de la solicitud SCIM; comprueba su respuesta y el acceso afectado, en lugar de considerar un evento de RRHH como prueba de una revocación completada. SCIM no elimina cuentas del sistema operativo.
• Groups lleva los datos de referencia de identidad-a-grupo. Cada grupo puede mapearse a un rol del control plane mediante mapped_role — y ese mapeo es propiedad del operador: se establece en el lado del control plane y se audita (scim.group.role.map); un push del IdP nunca escala un rol de forma silenciosa. Los miembros desconocidos de un grupo enviado se omiten y se auditan, no se inventan.

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

Las fuentes de roster alimentan el inventario de identidad del módulo VI y —este es el punto— dan al módulo III los bindings que elevan la atribución:

{
  "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>" }
    }
  ]
}

Opciones clave de LDAP (del descriptor que se envía): user_filter / group_filter, privileged_group_dns (grupos cuya pertenencia es en sí misma una señal de acceso privilegiado), nhi_dn_suffix (qué subárbol contiene las identidades no humanas), start_tls, page_size. El kind idp admite provider: okta (con api_token) o provider: entra (con tenant_id / client_id / client_secret); okta y entra también funcionan directamente como el kind.

Cómo eleva esto la atribución — con precisión

Una fuente de roster registra identidades (por external id) y, allí donde el directorio las declara, concesiones permitidas. Cuando el origen de una arista observada coincide con una identidad de roster no compartida, el módulo III liga el acceso a esa identidad y la confianza de la arista se eleva a attributed. Las identidades que varios workloads comparten permanecen honestamente como approximate — el roster no puede des-compartir una credencial; solo emitir identidad por agente puede hacerlo (el puente hacia la gobernanza).

Los kinds dedicados de identidad-de-agente e identidad-de-workload (las fuentes de federación de agentes — Entra Agent ID, AgentCore, SPIFFE y similares) son la señal firme por agente; los rosters de grupo/directorio afinan las personas y las cuentas de servicio.

Límites honestos

• Community incluye SSO con un único IdP. La selección entre varios IdP y el mapeo de grupos durante el acceso los proporciona el módulo privado de identidad correspondiente. La gestión general de usuarios, grupos y permisos sigue disponible en Community.
• Un roster no puede arreglar una credencial compartida. Solo puede decirte, honestamente, que la credencial es compartida.
• SCIM es aprovisionamiento entrante — el control plane no empuja identidades de vuelta a tu IdP, y el receptor de Security-Event-Token es una superficie entrante, no un webhook saliente.

Relacionado

• Conectar una fuente — por qué la identidad es la dependencia dura.
• Gobernar y aprobar — roles, RBAC y qué concede un mapped_role.
• Conectores y niveles de cobertura — la lista completa de fuentes de identidad (Vault, Infisical, Keycloak, SPIFFE, los kinds de federación de identidad de agentes).