Configuració de la integració d'Okta

Overview

Okta pot aportar activitat normalitzada del cicle de vida dels usuaris, d’autenticació, d’MFA i d’administració. Alguns exemples revisats són:

account.locked — compte bloquejat
mfa.factor.activated — activa factors d’MFA addicionals
auth.login.failed — no pot iniciar la sessió

Tots dos mètodes de connexió llegeixen els mateixos dos fluxos: el directori d’usuaris (/api/v1/users) i el registre del sistema (/api/v1/logs). Consulteu com les dades d’integració es converteixen en Signals.

Trieu un mètode de connexió

	Okta (SSWS)	Okta (OAuth 2.0)
Credencial	Un token d’API que creeu a l’Admin Console	Un ID de client i una JWK privada que genereu i registreu
Configuració	Tres passos, sense material de claus per generar	Nou passos, inclòs un parell de claus RSA
Rol d’administrador requerit	Administrador de només lectura, assignat al propietari del token	Administrador de només lectura, assignat a l’aplicació
Durada del token	Es desactiva després de 30 dies sense ús	No caduca; la rotació del parell de claus és responsabilitat vostra
Useu-lo quan	És el camí recomanat per a la majoria d’organitzacions	La vostra política de seguretat prohibeix els tokens d’API de llarga durada

Tots dos mètodes necessiten el mateix accés, de manera que l’elecció depèn de la gestió de les credencials, no del que la plataforma pot llegir.

Opció A — Token d’API (SSWS)

Recomanada.

Què necessita Living Security

Credencial	Descripció
API key	Un token d’API d’Okta. El diàleg de connexió anomena aquest camp API key
Tenant subdomain	El `<tenant>` de `<tenant>.okta.com`: només el subdomini, no l’URL completa

Requisits previs

Heu de ser Super Administrator d’Okta per crear un usuari de compte de servei, assignar rols d’administrador i crear tokens d’API.

Creeu un usuari propietari del token

Un token d’API d’Okta té els permisos de l’usuari que l’ha creat i deixa de funcionar si aquest usuari es desactiva. Creeu un compte de servei dedicat en lloc d’utilitzar un compte d’administrador personal, de manera que la connexió sobrevisqui als canvis de personal.

A l’Admin Console, aneu a Directory → People.
Feu clic a Add person i creeu un usuari com ara svc-livingsecurity@yourcompany.com.
Activeu el compte.

Assigneu el rol d'administrador de només lectura

La plataforma només llegeix. Concedir més que accés de lectura dona al token permisos que no utilitzarà mai.

Aneu a Security → Administrators.
Feu clic a Add administrator i seleccioneu l’usuari del pas anterior.
Assigneu el rol Read-only Administrator.
Deseu els canvis.

Sense un rol d’administrador, les crides a l’API Management d’Okta s’completen amb 200 OK i retornen una llista buida. No hi ha cap 403 que indiqui que falta el rol: els fluxos simplement queden buits.

Creeu el token d'API

Inicieu la sessió a l’Admin Console com a l’usuari del compte de servei del pas 1. El token hereta els permisos del compte que el crea.
Aneu a Security → API i obriu la pestanya Tokens.
Feu clic a Create token, poseu-li un nom com ara Living Security Platform i feu clic a Create token.
Copieu ara el valor del token: Okta el mostra una sola vegada i no el tornarà a mostrar.

Okta desactiva un token d’API després de 30 dies sense ús. Les sincronitzacions d’aquesta integració s’executen almenys un cop al dia, de manera que una connexió activa manté viu el seu token. Una connexió que es deixi en pausa durant un mes necessitarà un token nou.

La llista d’adreces anterior només és rellevant si la vostra organització d’Okta restringeix l’accés a l’API per network zone. La majoria d’organitzacions no ho fan.

Cerqueu el subdomini del vostre tenant

L’URL de l’Admin Console té un aspecte com https://acme-admin.okta.com. El subdomini del tenant és acme, sense el sufix -admin, sense .okta.com i sense https://.

Ara esteu connectat a Okta (SSWS).

Resolució de problemes

401 Unauthorized

El token no és vàlid, s’ha revocat o s’ha desactivat després de 30 dies d’inactivitat. Creeu un token nou com a usuari del compte de servei i torneu-lo a introduir a la connexió.

Connectat, però tots els fluxos són buits

El propietari del token no té cap rol d’administrador. Assigneu Read-only Administrator al compte de servei (pas 2): l’API retorna 200 OK amb una llista buida en lloc d’un error quan falta el rol.

Les sincronitzacions fallen després d'un canvi de personal

El token deixa de funcionar si l’usuari que el va crear es desactiva. Per això el token ha de pertànyer a un compte de servei i no a una persona.

Opció B — Aplicació de servei OAuth 2.0

Utilitzeu aquest mètode quan la vostra política de seguretat no permeti tokens d’API de llarga durada. Substitueix el token per un ID de client i un parell de claus RSA que són vostres. A la plataforma és el mosaic Okta (OAuth 2.0), a Settings → Integrations → Catalog. Per autenticar-vos amb Okta mitjançant Client Credentials, necessiteu el següent:

Client ID - Un identificador únic per a la vostra aplicació Okta API Services.
Private Key (JWK) - La clau privada RSA en format JSON Web Key, la clau pública de la qual està registrada a la vostra aplicació d’Okta.
Okta Domain - Només el subdomini del vostre tenant d’Okta (p. ex. dev-12345678), no el nom d’amfitrió complet.
Scopes - Una llista d’àmbits de l’API Management d’Okta separats per espais (p. ex. okta.users.read okta.logs.read).

Aquesta guia us explicarà com crear una aplicació API Services a Okta amb autenticació private_key_jwt.

Requisits previs:

Heu de tenir un compte d’Okta. Podeu registrar-vos per obtenir un compte de desenvolupador gratuït a developer.okta.com.

Pas 1: Creació de l’aplicació Okta API Services

Inicieu la sessió a l’Okta Admin Console.
A la barra lateral esquerra, aneu a Applications > Applications.
Feu clic a Create App Integration.
Seleccioneu API Services com a mètode d’inici de sessió i feu clic a Next.

Poseu un nom a l’aplicació i feu clic a Save.
A la pestanya General de l’aplicació, cerqueu el Client ID: el necessitareu en el pas final.
Establiu Client authentication a Public key / Private key. Els àmbits okta.* només són compatibles amb aquest mètode d’autenticació.

Desactiveu Proof of possession (DPoP): no és compatible.

L’aplicació s’ha de crear com a API Services.

Pas 2: Generació i registre del parell de claus RSA

Utilitzeu el generador de claus d’Okta

Okta pot generar el parell de claus RSA directament a l’Admin Console:

A l’Admin Console, obriu la vostra aplicació API Services.
Aneu a la pestanya General i desplaceu-vos fins a la secció PUBLIC KEYS.
Feu clic a Add Key i, a continuació, seleccioneu Generate new key.
Feu clic a Save: Okta genera el parell de claus i mostra la Private Key (JWK) una sola vegada.
Copieu i deseu immediatament el JSON de la clau privada: no es tornarà a mostrar.

La clau pública es registra automàticament a la vostra aplicació.

Copieu la JWK privada abans de tancar el diàleg. Enganxeu-la al camp Private Key de la Living Security Platform en el pas final.

Creeu la vostra pròpia clau

Okta utilitza private_key_jwt per a les aplicacions API Services. Genereu un parell de claus RSA, registreu la JWK pública a Okta i proporcioneu la JWK privada a la Living Security Platform. Genereu una JWK privada amb el script de Node.js següent (requereix 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));

Registreu la JWK pública a Okta:

A l’Admin Console, obriu la vostra aplicació API Services.
Aneu a la pestanya General i desplaceu-vos fins a la secció PUBLIC KEYS.
Feu clic a Add Key, enganxeu el JSON de la JWK pública generat pel script anterior i feu clic a Save.

La JWK privada és la que enganxeu a la Living Security Platform. Inclou tot el material de la clau (d, p, q, dp, dq, qi) i el kid. Mantingueu-la en secret.

Pas 3: Cerca del vostre Okta Domain

Introduïu només el subdomini del vostre tenant d’Okta: la part anterior a .okta.com.

A l’Admin Console, la barra d’adreces del navegador mostrarà un URL com https://dev-12345678-admin.okta.com.
El vostre Okta Domain és només el subdomini (p. ex., dev-12345678), no dev-12345678.okta.com.
Alternativament, aneu a Settings > Account a l’Admin Console per trobar el vostre domini d’Okta i feu servir la part del subdomini.

Pas 4: Concessió d’àmbits d’API a l’aplicació

Okta requereix almenys un àmbit a cada sol·licitud de token. Perquè l’aplicació pugui sol·licitar àmbits concrets, primer s’han de concedir:

A l’Admin Console, aneu a Applications > Applications i obriu la vostra aplicació.
Feu clic a la pestanya Okta API Scopes.
Concediu els àmbits que requereix la vostra integració: okta.users.read i okta.logs.read.

Trobareu una llista completa dels àmbits disponibles a la referència de l’API Management d’Okta.

Pas 5: Assignació d’un rol d’administrador a l’aplicació

Concedir només àmbits no és suficient: els punts finals de l’API Management d’Okta (p. ex. /api/v1/users) retornen silenciosament una resposta 200 [] buida si l’aplicació no té cap rol d’administrador. Heu d’assignar com a mínim Read-Only Administrator:

A l’Admin Console, aneu a Security > Administrators (o aneu a Applications > Applications > la vostra aplicació > Admin roles).
Feu clic a Add administrator assignment i seleccioneu la vostra aplicació API Services.

Assigneu el rol Read-Only Administrator (o superior, segons els àmbits que necessiteu).
Feu clic a Save.

Sense un rol d’administrador, les crides a l’API s’completen amb 200 OK però retornen resultats buits i no hi ha cap error 403 que indiqui el problema.

Pas 6: Introducció de les credencials a la Living Security Platform

Quan tingueu el Client ID, la Private Key (JWK), l’Okta Domain i els Scopes:

Obriu el formulari on heu d’autenticar-vos amb Okta (Client Credentials).
Introduïu el vostre Client ID.
Enganxeu la vostra Private Key (JWK): l’objecte JSON complet del script anterior (en una sola línia o amb format).
Introduïu el vostre Okta Domain només com a subdomini del tenant (p. ex., dev-12345678).
Introduïu els Scopes com a llista separada per espais (p. ex., okta.users.read okta.logs.read).
Envieu el formulari i hauríeu d’autenticar-vos correctament.

Ara esteu connectat a Okta (Client Credentials).

Parts d’aquesta documentació s’han adaptat de Nango, utilitzat sota la Elastic License 2.0.

Integrations

Configuració de la integració

Catàleg

Canals de sortida

Overview

Trieu un mètode de connexió