Configuración de la integración con Okta

Descripción general

Okta puede aportar actividad normalizada del ciclo de vida de los usuarios, de autenticación, de MFA y administrativa. Entre los ejemplos revisados se incluyen:

account.locked — cuenta bloqueada
mfa.factor.activated — activa factores de MFA adicionales
auth.login.failed — no logra iniciar sesión

Ambos métodos de conexión leen los mismos dos flujos: el directorio de usuarios (/api/v1/users) y el registro del sistema (/api/v1/logs). Consulte cómo los datos de las integraciones se convierten en señales.

Elija un método de conexión

	Okta (SSWS)	Okta (OAuth 2.0)
Credencial	Un token de API que usted crea en la Admin Console	Un ID de cliente y una JWK privada que usted genera y registra
Configuración	Tres pasos, sin material de claves que generar	Nueve pasos, incluido un par de claves RSA
Rol de administrador necesario	Administrador de solo lectura, asignado al propietario del token	Administrador de solo lectura, asignado a la aplicación
Vigencia del token	Se desactiva tras 30 días sin uso	No caduca; la rotación del par de claves le corresponde a usted
Úselo cuando	Esta es la opción recomendada para la mayoría de las organizaciones	Su política de seguridad prohíbe los tokens de API de larga duración

Ambos métodos requieren el mismo acceso, por lo que la elección depende del manejo de las credenciales y no de lo que la plataforma puede leer.

Opción A: token de API (SSWS)

Recomendada.

Qué necesita Living Security

Credencial	Descripción
Clave de API	Un token de API de Okta. El cuadro de diálogo de conexión denomina este campo Clave de API
Subdominio del tenant	El `<tenant>` en `<tenant>.okta.com`: solo el subdominio, no la URL completa

Requisitos previos

Debe ser Super Administrator de Okta para crear un usuario de cuenta de servicio, asignar roles de administrador y crear tokens de API.

Cree un usuario que sea propietario del token

Un token de API de Okta tiene los permisos del usuario que lo creó y deja de funcionar si ese usuario se desactiva. Cree una cuenta de servicio dedicada en lugar de usar una cuenta de administrador personal, de modo que la conexión se mantenga ante cambios de personal.

En la Admin Console, vaya a Directory → People.
Haga clic en Add person y cree un usuario como svc-livingsecurity@yourcompany.com.
Active la cuenta.

Asigne el rol de administrador de solo lectura

La plataforma solo realiza lecturas. Otorgar más que acceso de lectura concede al token permisos que nunca utiliza.

Vaya a Seguridad → Administrators.
Haga clic en Add administrator y seleccione el usuario del paso anterior.
Asigne el rol Read-only Administrator.
Haga clic en Guardar.

Sin un rol de administrador, las llamadas a la Okta Management API se realizan correctamente con 200 OK y devuelven una lista vacía. No hay ningún 403 que le indique que falta el rol: los flujos simplemente permanecen vacíos.

Cree el token de API

Inicie sesión en la Admin Console como el usuario de la cuenta de servicio del paso 1. El token hereda los permisos de la cuenta que lo crea.
Vaya a Seguridad → API y abra la pestaña Tokens.
Haga clic en Create token, asígnele un nombre como Living Security Platform y haga clic en Create token.
Copie ahora el valor del token: Okta lo muestra una sola vez y no vuelve a mostrarlo.

Okta desactiva un token de API tras 30 días sin uso. Las sincronizaciones de esta integración se ejecutan al menos una vez al día, por lo que una conexión activa mantiene vigente su propio token. Una conexión que permanezca en pausa durante un mes necesitará un token nuevo.

La lista de direcciones anterior solo es relevante si su organización de Okta restringe el acceso a la API mediante zonas de red. La mayoría de las organizaciones no lo hace.

Localice el subdominio de su tenant

La URL de su Admin Console tiene este aspecto: https://acme-admin.okta.com. El subdominio del tenant es acme, sin el sufijo -admin, sin .okta.com y sin https://.

Ya está conectado a Okta (SSWS).

Solución de problemas

401 Unauthorized

El token no es válido, fue revocado o se desactivó tras 30 días de inactividad. Cree un token nuevo como el usuario de la cuenta de servicio y vuelva a introducirlo en la conexión.

Conectado, pero todos los flujos están vacíos

El propietario del token no tiene ningún rol de administrador. Asigne Read-only Administrator a la cuenta de servicio (paso 2): cuando falta el rol, la API devuelve 200 OK con una lista vacía en lugar de un error.

Las sincronizaciones fallan tras un cambio de personal

El token deja de funcionar si se desactiva al usuario que lo creó. Por eso el token debe pertenecer a una cuenta de servicio y no a una persona.

Opción B: aplicación de servicio OAuth 2.0

Utilice este método cuando su política de seguridad no permita tokens de API de larga duración. Sustituye el token por un ID de cliente y un par de claves RSA de su propiedad. En la plataforma, corresponde al icono Okta (OAuth 2.0), en Configuración → Integraciones → Catálogo. Para autenticarse con Okta mediante Client Credentials, necesita lo siguiente:

ID de cliente: un identificador único para su aplicación Okta API Services.
Clave privada (JWK): la clave privada RSA en formato JSON Web Key, cuya clave pública está registrada en su aplicación de Okta.
Dominio de Okta: solo el subdominio de su tenant de Okta (por ejemplo, dev-12345678), no el nombre de host completo.
Ámbitos: una lista de ámbitos de la Okta Management API separados por espacios (por ejemplo, okta.users.read okta.logs.read).

Esta guía le explica cómo crear en Okta una aplicación API Services con autenticación private_key_jwt.

Requisitos previos:

Debe tener una cuenta de Okta. Puede registrarse para obtener una cuenta de desarrollador gratuita en developer.okta.com.

Paso 1: Cree su aplicación Okta API Services

Inicie sesión en su Okta Admin Console.
En la barra lateral izquierda, vaya a Applications > Applications.
Haga clic en Create App Integration.
Seleccione API Services como método de inicio de sesión y haga clic en Siguiente.

Asigne un nombre a su aplicación y haga clic en Guardar.
En la pestaña General de la aplicación, localice su ID de cliente; lo necesitará en el paso final.
Establezca Client authentication en Public key / Private key. Los ámbitos okta.* solo son compatibles con este método de autenticación.

Desactive Proof of possession (DPoP), ya que no es compatible.

La aplicación debe crearse como API Services.

Paso 2: Genere y registre su par de claves RSA

Use el generador de claves de Okta

Okta puede generar el par de claves RSA por usted directamente en la Admin Console:

En la Admin Console, abra su aplicación API Services.
Vaya a la pestaña General y desplácese hasta la sección PUBLIC KEYS.
Haga clic en Add Key y, a continuación, seleccione Generate new key.
Haga clic en Guardar: Okta genera el par de claves y muestra la clave privada (JWK) una sola vez.
Copie y guarde de inmediato el JSON de la clave privada; no se volverá a mostrar.

La clave pública se registra automáticamente en su aplicación.

Copie la JWK privada antes de cerrar el cuadro de diálogo. Péguela en el campo Clave privada de Living Security Platform en el paso final.

Cree su propia clave

Okta utiliza private_key_jwt para las aplicaciones API Services. Usted genera un par de claves RSA, registra la JWK pública en Okta y proporciona la JWK privada a Living Security Platform. Genere una JWK privada con el siguiente script de Node.js (requiere Node.js 18+):

const { generateKeyPairSync } = require('crypto');
const { privateKey, publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });

const privateJwk = privateKey.export({ format: 'jwk' });
const publicJwk  = publicKey.export({ format: 'jwk' });

// Assign a kid — must match between private and public JWK
const kid = require('crypto').randomUUID();
privateJwk.kid = kid;
publicJwk.kid  = kid;

console.log('=== PUBLIC JWK (upload to Okta) ===');
console.log(JSON.stringify(publicJwk, null, 2));
console.log('\n=== PRIVATE JWK (paste into the Living Security Platform) ===');
console.log(JSON.stringify(privateJwk));

Registre la JWK pública en Okta:

En la Admin Console, abra su aplicación API Services.
Vaya a la pestaña General y desplácese hasta la sección PUBLIC KEYS.
Haga clic en Add Key, pegue el JSON de la JWK pública generado por el script anterior y haga clic en Guardar.

La JWK privada es la que pega en Living Security Platform. Incluye todo el material de la clave (d, p, q, dp, dq, qi) y el kid. Manténgala en secreto.

Paso 3: Localice su dominio de Okta

Introduzca únicamente el subdominio de su tenant de Okta: la parte anterior a .okta.com.

En la Admin Console, la barra de direcciones del navegador mostrará una URL como https://dev-12345678-admin.okta.com.
Su Dominio de Okta es solo el subdominio (por ejemplo, dev-12345678), no dev-12345678.okta.com.
Como alternativa, vaya a Configuración > Account en la Admin Console para encontrar su dominio de Okta y utilice la parte del subdominio.

Paso 4: Conceda ámbitos de API a su aplicación

Okta exige al menos un ámbito en cada solicitud de token. Antes de que su aplicación pueda solicitar ámbitos específicos, estos deben estar concedidos:

En la Admin Console, vaya a Applications > Applications y abra su aplicación.
Haga clic en la pestaña Okta API Scopes.
Conceda los ámbitos que requiere su integración: okta.users.read y okta.logs.read.

Encontrará una lista completa de los ámbitos disponibles en la referencia de Okta Management API.

Paso 5: Asigne un rol de administrador a su aplicación

Conceder ámbitos no es suficiente: los endpoints de la Okta Management API (por ejemplo, /api/v1/users) devuelven silenciosamente una respuesta 200 [] vacía si su aplicación no tiene un rol de administrador. Debe asignar como mínimo Read-Only Administrator:

En la Admin Console, vaya a Seguridad > Administrators (o a Applications > Applications > su aplicación > Admin roles).
Haga clic en Add administrator assignment y seleccione su aplicación API Services.

Asigne el rol Read-Only Administrator (o superior, según los ámbitos que necesite).
Haga clic en Guardar.

Sin un rol de administrador, las llamadas a la API se realizan correctamente con 200 OK pero devuelven resultados vacíos, y no hay ningún error 403 que indique el problema.

Paso 6: Introduzca las credenciales en Living Security Platform

Una vez que disponga de su ID de cliente, su clave privada (JWK), su dominio de Okta y sus ámbitos:

Abra el formulario en el que necesite autenticarse con Okta (Client Credentials).
Introduzca su ID de cliente.
Pegue su clave privada (JWK): el objeto JSON completo del script anterior (en una sola línea o con formato).
Introduzca su dominio de Okta solo como el subdominio del tenant (por ejemplo, dev-12345678).
Introduzca los ámbitos como una lista separada por espacios (por ejemplo, okta.users.read okta.logs.read).
Envíe el formulario y debería quedar autenticado correctamente.

Ya está conectado a Okta (Client Credentials).

Partes de esta documentación están adaptadas de Nango, utilizada bajo la Elastic License 2.0.

Integraciones

Configuración de integraciones

Catálogo

Canales de salida

Configuración de la integración con Okta

Descripción general

Elija un método de conexión