Configurarea integrării Okta

Prezentare generală

Okta poate furniza activitate normalizată privind ciclul de viață al utilizatorilor, autentificarea, MFA și activitatea administrativă. Exemplele analizate includ:

account.locked — cont blocat
mfa.factor.activated — activează factori MFA suplimentari
auth.login.failed — eșuează la autentificare

Ambele metode de conectare citesc aceleași două fluxuri — directorul de utilizatori (/api/v1/users) și jurnalul de sistem (/api/v1/logs). Consultați cum devin datele de integrare semnale.

Alegeți o metodă de conectare

	Okta (SSWS)	Okta (OAuth 2.0)
Credențiale	Un token API pe care îl creați în Admin Console	Un ID client și un JWK privat pe care le generați și le înregistrați
Configurare	Trei pași, fără material criptografic de generat	Nouă pași, inclusiv o pereche de chei RSA
Rol de administrator necesar	Administrator cu drepturi de citire (read-only), atribuit proprietarului token-ului	Administrator cu drepturi de citire (read-only), atribuit aplicației
Durata de viață a token-ului	Se dezactivează după 30 de zile fără utilizare	Nu expiră; rotirea perechii de chei vă revine dumneavoastră
Utilizați când	Aceasta este calea recomandată pentru majoritatea organizațiilor	Politica dumneavoastră de securitate interzice token-urile API cu durată lungă de viață

Ambele metode necesită același acces, deci alegerea ține de gestionarea credențialelor, nu de ceea ce poate citi platforma.

Opțiunea A — Token API (SSWS)

Recomandat.

Ce are nevoie Living Security

Credențiale	Descriere
Cheie API	Un token API Okta. Dialogul de conectare etichetează acest câmp Cheie API
Subdomeniu tenant	`<tenant>` din `<tenant>.okta.com` — doar subdomeniul, nu URL-ul complet

Cerințe preliminare

Trebuie să fiți Super Administrator în Okta pentru a crea un utilizator de cont de serviciu, a atribui roluri de administrator și a crea token-uri API.

Creați un utilizator care să dețină token-ul

Un token API Okta are permisiunile utilizatorului care l-a creat și nu mai funcționează dacă acel utilizator este dezactivat. Creați un cont de serviciu dedicat în loc să utilizați un cont personal de administrator, astfel încât conexiunea să reziste schimbărilor de personal.

În Admin Console, accesați Directory → People.
Faceți clic pe Add person și creați un utilizator precum svc-livingsecurity@yourcompany.com.
Activați contul.

Atribuiți rolul de administrator cu drepturi de citire

Platforma doar citește. Acordarea de drepturi mai mari decât cele de citire oferă token-ului permisiuni pe care nu le utilizează niciodată.

Accesați Security → Administrators.
Faceți clic pe Add administrator și selectați utilizatorul din pasul anterior.
Atribuiți rolul Read-only Administrator.
Save.

Fără un rol de administrator, apelurile către Okta Management API reușesc cu 200 OK și returnează o listă goală. Nu există 403 care să vă indice că rolul lipsește — fluxurile rămân pur și simplu goale.

Creați token-ul API

Conectați-vă la Admin Console ca utilizator al contului de serviciu din pasul 1. Token-ul moștenește drepturile contului care îl creează.
Accesați Security → API și deschideți fila Tokens.
Faceți clic pe Create token, denumiți-l, de exemplu Living Security Platform, apoi faceți clic pe Create token.
Copiați acum valoarea token-ului — Okta o afișează o singură dată.

Okta dezactivează un token API după 30 de zile fără utilizare. Sincronizările din această integrare rulează cel puțin o dată pe zi, deci o conexiune activă își menține în viață propriul token. O conexiune lăsată în pauză o lună necesită un token nou.

Lista de adrese de mai sus este relevantă doar dacă organizația dumneavoastră Okta restricționează accesul API în funcție de network zone. Majoritatea organizațiilor nu fac acest lucru.

Găsiți subdomeniul tenantului

URL-ul Admin Console arată astfel: https://acme-admin.okta.com. Subdomeniul tenantului este acme — fără sufixul -admin, fără .okta.com și fără https://.

Acum sunteți conectat la Okta (SSWS).

Depanare

401 Unauthorized

Token-ul este nevalid, a fost revocat sau a fost dezactivat după 30 de zile de inactivitate. Creați un token nou ca utilizator al contului de serviciu și introduceți-l din nou în conexiune.

Conectat, dar toate fluxurile sunt goale

Proprietarul token-ului nu are un rol de administrator. Atribuiți Read-only Administrator contului de serviciu (pasul 2) — API-ul returnează 200 OK cu o listă goală, în loc de o eroare, atunci când rolul lipsește.

Sincronizările eșuează după o schimbare de personal

Token-ul nu mai funcționează dacă utilizatorul care l-a creat este dezactivat. Din acest motiv, token-ul trebuie să aparțină unui cont de serviciu, nu unei persoane.

Opțiunea B — Aplicație de serviciu OAuth 2.0

Utilizați această metodă atunci când politica dumneavoastră de securitate nu permite token-uri API cu durată lungă de viață. Ea înlocuiește token-ul cu un ID client și o pereche de chei RSA pe care le dețineți dumneavoastră. În platformă, aceasta este tile-ul Okta (OAuth 2.0), din Setări → Integrari → Catalog. Pentru a vă autentifica în Okta folosind Client Credentials, aveți nevoie de următoarele:

ID client - Un identificator unic pentru aplicația dumneavoastră Okta API Services.
Cheie privată (JWK) - Cheia privată RSA în format JSON Web Key, a cărei cheie publică este înregistrată în aplicația dumneavoastră Okta.
Domeniu Okta - Doar subdomeniul tenantului dumneavoastră Okta (de exemplu dev-12345678), nu numele complet de gazdă.
Scope-uri - O listă de scope-uri Okta Management API separate prin spațiu (de exemplu okta.users.read okta.logs.read).

Acest ghid vă va îndruma în crearea unei aplicații API Services în Okta cu autentificare private_key_jwt.

Cerințe preliminare:

Trebuie să aveți un cont Okta. Puteți crea un cont gratuit de dezvoltator la developer.okta.com.

Pasul 1: Crearea aplicației Okta API Services

Conectați-vă la Okta Admin Console.
În bara laterală din stânga, accesați Applications > Applications.
Faceți clic pe Create App Integration.
Selectați API Services ca metodă de autentificare și faceți clic pe Next.

Denumiți aplicația și faceți clic pe Save.
În fila General a aplicației, găsiți Client ID — veți avea nevoie de el în ultimul pas.
Setați Client authentication la Public key / Private key. Scope-urile okta.* sunt acceptate doar cu această metodă de autentificare.

Dezactivați Proof of possession (DPoP) — nu este acceptat.

Aplicația trebuie creată ca API Services.

Pasul 2: Generarea și înregistrarea perechii de chei RSA

Utilizați generatorul de chei Okta

Okta poate genera pentru dumneavoastră perechea de chei RSA direct în Admin Console:

În Admin Console, deschideți aplicația API Services.
Accesați fila General și derulați până la secțiunea PUBLIC KEYS.
Faceți clic pe Add Key, apoi selectați Generate new key.
Faceți clic pe Save — Okta generează perechea de chei și afișează Private Key (JWK) o singură dată.
Copiați și salvați imediat JSON-ul cheii private — nu va mai fi afișat din nou.

Cheia publică este înregistrată automat în aplicația dumneavoastră.

Copiați JWK-ul privat înainte de a închide dialogul. Lipiți-l în câmpul Cheie privată din Living Security Platform, în ultimul pas.

Creați propria cheie

Okta utilizează private_key_jwt pentru aplicațiile API Services. Generați o pereche de chei RSA, înregistrați JWK-ul public în Okta și furnizați JWK-ul privat către Living Security Platform. Generați un JWK privat utilizând următorul script Node.js (necesită 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));

Înregistrați JWK-ul public în Okta:

În Admin Console, deschideți aplicația API Services.
Accesați fila General și derulați până la secțiunea PUBLIC KEYS.
Faceți clic pe Add Key, lipiți JSON-ul JWK public rezultat din scriptul de mai sus și faceți clic pe Save.

JWK-ul privat este cel pe care îl lipiți în Living Security Platform. Acesta include tot materialul cheii (d, p, q, dp, dq, qi) și kid. Păstrați-l secret.

Pasul 3: Găsirea domeniului Okta

Introduceți doar subdomeniul tenantului dumneavoastră Okta — partea dinaintea .okta.com.

În Admin Console, bara de adrese a browserului va afișa un URL precum https://dev-12345678-admin.okta.com.
Domeniul Okta este doar subdomeniul (de exemplu, dev-12345678), nu dev-12345678.okta.com.
Alternativ, accesați Settings > Account în Admin Console pentru a găsi domeniul Okta, apoi utilizați partea de subdomeniu.

Pasul 4: Acordarea scope-urilor API aplicației

Okta necesită cel puțin un scope în fiecare solicitare de token. Înainte ca aplicația să poată solicita anumite scope-uri, acestea trebuie acordate:

În Admin Console, accesați Applications > Applications și deschideți aplicația.
Faceți clic pe fila Okta API Scopes.
Acordați scope-urile necesare integrării dumneavoastră: okta.users.read și okta.logs.read.

O listă completă a scope-urilor disponibile se găsește în referința Okta Management API.

Pasul 5: Atribuirea unui rol de administrator aplicației

Acordarea scope-urilor nu este suficientă — endpoint-urile Okta Management API (de exemplu /api/v1/users) returnează în mod silențios un răspuns 200 [] gol dacă aplicația dumneavoastră nu are un rol de administrator. Trebuie să atribuiți cel puțin Read-Only Administrator:

În Admin Console, accesați Security > Administrators (sau accesați Applications > Applications > aplicația dumneavoastră > Admin roles).
Faceți clic pe Add administrator assignment și selectați aplicația API Services.

Atribuiți rolul Read-Only Administrator (sau unul superior, în funcție de scope-urile de care aveți nevoie).
Faceți clic pe Save.

Fără un rol de administrator, apelurile API reușesc cu 200 OK, dar returnează rezultate goale și nu există nicio eroare 403 care să indice problema.

Pasul 6: Introducerea credențialelor în Living Security Platform

După ce aveți ID client, Cheie privată (JWK), Domeniu Okta și Scope-uri:

Deschideți formularul în care trebuie să vă autentificați în Okta (Client Credentials).
Introduceți ID client.
Lipiți Cheie privată (JWK) — obiectul JSON complet din scriptul de mai sus (pe o singură linie sau formatat).
Introduceți Domeniu Okta doar ca subdomeniu al tenantului (de exemplu, dev-12345678).
Introduceți Scope-uri ca listă separată prin spații (de exemplu, okta.users.read okta.logs.read).
Trimiteți formularul și ar trebui să fiți autentificat cu succes.

Acum sunteți conectat la Okta (Client Credentials).

Porțiuni din această documentație sunt adaptate după Nango, utilizate sub Elastic License 2.0.

Integrări

Configurarea integrărilor

Catalog

Canale de ieșire

Prezentare generală

Alegeți o metodă de conectare