Nastavení integrace Okta - Living Security Platform

Přehled

Okta může poskytovat normalizovaná data o životním cyklu uživatelů, autentizaci, MFA a administrativní aktivitě. Mezi prověřené příklady patří:

account.locked — účet byl uzamčen
mfa.factor.activated — aktivuje další faktory MFA
auth.login.failed — se nepodaří přihlásit

Obě metody připojení čtou stejné dva datové toky — adresář uživatelů (/api/v1/users) a systémový log (/api/v1/logs). Viz jak se data z integrací mění na signály.

Výběr metody připojení

	Okta (SSWS)	Okta (OAuth 2.0)
Přihlašovací údaje	Token API, který vytvoříte v konzoli Admin Console	ID klienta a privátní JWK, který vygenerujete a zaregistrujete
Nastavení	Tři kroky, bez generování klíčového materiálu	Devět kroků, včetně páru klíčů RSA
Požadovaná role správce	Správce s oprávněním pouze pro čtení, přiřazená vlastníkovi tokenu	Správce s oprávněním pouze pro čtení, přiřazená aplikaci
Platnost tokenu	Deaktivuje se po 30 dnech nepoužívání	Bez expirace; rotace páru klíčů je ve vaší správě
Kdy metodu použít	Doporučená volba pro většinu organizací	Vaše bezpečnostní politika zakazuje dlouhodobě platné tokeny API

Obě metody vyžadují stejný přístup, takže volba se týká správy přihlašovacích údajů, nikoli toho, co platforma může číst.

Varianta A — token API (SSWS)

Doporučeno.

Co Living Security potřebuje

Přihlašovací údaj	Popis
Klíč API	Token API služby Okta. V dialogu připojení je toto pole označeno jako Klíč API
Subdoména tenanta	`<tenant>` v `<tenant>.okta.com` — pouze samotná subdoména, nikoli celá adresa URL

Předpoklady

Abyste mohli vytvořit uživatele servisního účtu, přiřadit role správce a vytvářet tokeny API, musíte být v Okta Super Administrator.

Vytvoření uživatele, který bude token vlastnit

Token API služby Okta má oprávnění uživatele, který jej vytvořil, a přestane fungovat, pokud je tento uživatel deaktivován. Vytvořte proto vyhrazený servisní účet místo osobního administrátorského účtu, aby připojení přežilo personální změny.

V konzoli Admin Console přejděte do Directory → People.
Klikněte na Add person a vytvořte uživatele, například svc-livingsecurity@yourcompany.com.
Aktivujte účet.

Přiřazení role správce s oprávněním pouze pro čtení

Platforma pouze čte. Udělení širších oprávnění než pro čtení by tokenu poskytlo oprávnění, která nikdy nevyužije.

Přejděte do Zabezpečení → Administrators.
Klikněte na Add administrator a vyberte uživatele z předchozího kroku.
Přiřaďte roli Read-only Administrator.
Uložte.

Bez role správce volání rozhraní Okta Management API proběhnou úspěšně s odpovědí 200 OK a vrátí prázdný seznam. Neexistuje žádné 403, které by vás upozornilo na chybějící roli — datové toky zůstanou prostě prázdné.

Vytvoření tokenu API

Přihlaste se do konzole Admin Console jako uživatel servisního účtu z kroku 1. Token zdědí oprávnění účtu, který jej vytvoří.
Přejděte do Zabezpečení → API a otevřete kartu Tokens.
Klikněte na Create token, zadejte název, například Living Security Platform, a klikněte na Create token.
Hodnotu tokenu nyní zkopírujte — Okta ji zobrazí pouze jednou a už nikdy více.

Okta deaktivuje token API po 30 dnech nepoužívání. Synchronizace v této integraci probíhají nejméně jednou denně, takže aktivní připojení udržuje svůj token naživu. Připojení, které zůstane pozastavené měsíc, bude vyžadovat nový token.

Výše uvedený seznam adres je důležitý pouze v případě, že vaše organizace Okta omezuje přístup k API pomocí síťové zóny. Většina organizací to nedělá.

Zjištění subdomény tenanta

Adresa URL vaší konzole Admin Console vypadá takto: https://acme-admin.okta.com. Subdoména tenanta je acme — bez přípony -admin, bez .okta.com a bez https://.

Nyní jste připojeni k Okta (SSWS).

Řešení potíží

401 Unauthorized

Token je neplatný, byl zrušen nebo byl deaktivován po 30 dnech nečinnosti. Vytvořte nový token jako uživatel servisního účtu a znovu jej zadejte v připojení.

Připojeno, ale všechny datové toky jsou prázdné

Vlastník tokenu nemá žádnou roli správce. Přiřaďte servisnímu účtu roli Read-only Administrator (krok 2) — pokud role chybí, API místo chyby vrací 200 OK s prázdným seznamem.

Synchronizace selhávají po personální změně

Token přestane fungovat, pokud je deaktivován uživatel, který jej vytvořil. Proto by měl token patřit servisnímu účtu, nikoli konkrétní osobě.

Varianta B — servisní aplikace OAuth 2.0

Tuto metodu použijte, pokud vaše bezpečnostní politika nepovoluje dlouhodobě platné tokeny API. Token nahrazuje ID klienta a pár klíčů RSA, který vlastníte. V platformě jde o dlaždici Okta (OAuth 2.0) v části Nastavení → Integrace → Katalog. Pro autentizaci v Okta pomocí Client Credentials potřebujete následující:

ID klienta – jedinečný identifikátor vaší aplikace Okta API Services.
Privátní klíč (JWK) – privátní klíč RSA ve formátu JSON Web Key, jehož veřejný klíč je zaregistrován ve vaší aplikaci Okta.
Doména Okta – pouze subdoména vašeho tenanta Okta (např. dev-12345678), nikoli celý název hostitele.
Rozsahy (scopes) – seznam rozsahů rozhraní Okta Management API oddělených mezerou (např. okta.users.read okta.logs.read).

Tento návod vás provede vytvořením aplikace API Services v Okta s autentizací private_key_jwt.

Předpoklady:

Musíte mít účet Okta. Bezplatný vývojářský účet si můžete zřídit na developer.okta.com.

Krok 1: Vytvoření aplikace Okta API Services

Přihlaste se do konzole Okta Admin Console.
V levém postranním panelu přejděte na Applications > Applications.
Klikněte na Create App Integration.
Jako metodu přihlášení vyberte API Services a klikněte na Další.

Zadejte název aplikace a klikněte na Uložit.
Na kartě General aplikace najděte své ID klienta — budete ho potřebovat v posledním kroku.
Nastavte Client authentication na Public key / Private key. Rozsahy okta.* jsou podporovány pouze s touto metodou autentizace.

Zakažte Proof of possession (DPoP) — není podporováno.

Aplikace musí být vytvořena jako API Services.

Krok 2: Vygenerování a registrace páru klíčů RSA

Použití generátoru klíčů Okta

Okta může pár klíčů RSA vygenerovat přímo v konzoli Admin Console:

V konzoli Admin Console otevřete svou aplikaci API Services.
Přejděte na kartu General a sjeďte do sekce PUBLIC KEYS.
Klikněte na Add Key a poté vyberte Generate new key.
Klikněte na Uložit — Okta vygeneruje pár klíčů a jednorázově zobrazí Privátní klíč (JWK).
Okamžitě zkopírujte a uložte JSON privátního klíče — znovu se již nezobrazí.

Veřejný klíč se automaticky zaregistruje ve vaší aplikaci.

Zkopírujte privátní JWK dříve, než dialog zavřete. V posledním kroku jej vložte do pole Privátní klíč v Living Security Platform.

Vytvoření vlastního klíče

Okta pro aplikace API Services používá private_key_jwt. Vygenerujete pár klíčů RSA, veřejný JWK zaregistrujete v Okta a privátní JWK poskytnete platformě Living Security Platform. Vygenerujte privátní JWK pomocí následujícího skriptu Node.js (vyžaduje 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));

Zaregistrujte veřejný JWK v Okta:

V konzoli Admin Console otevřete svou aplikaci API Services.
Přejděte na kartu General a sjeďte do sekce PUBLIC KEYS.
Klikněte na Add Key, vložte JSON veřejného JWK z výstupu výše uvedeného skriptu a klikněte na Uložit.

Do Living Security Platform vkládáte privátní JWK. Obsahuje veškerý klíčový materiál (d, p, q, dp, dq, qi) a kid. Uchovávejte jej v tajnosti.

Krok 3: Zjištění domény Okta

Zadejte pouze subdoménu svého tenanta Okta — část před .okta.com.

V konzoli Admin Console se v adresním řádku prohlížeče zobrazí adresa URL podobná https://dev-12345678-admin.okta.com.
Vaše doména Okta je pouze subdoména (např. dev-12345678), nikoli dev-12345678.okta.com.
Případně přejděte v konzoli Admin Console do Nastavení > Account, kde doménu Okta najdete, a poté použijte část se subdoménou.

Krok 4: Udělení rozsahů API vaší aplikaci

Okta vyžaduje alespoň jeden rozsah v každém požadavku na token. Než si vaše aplikace bude moci vyžádat konkrétní rozsahy, musí jí být uděleny:

V konzoli Admin Console přejděte na Applications > Applications a otevřete svou aplikaci.
Klikněte na kartu Okta API Scopes.
Udělte rozsahy, které vaše integrace vyžaduje: okta.users.read a okta.logs.read.

Úplný seznam dostupných rozsahů najdete v referenční dokumentaci Okta Management API.

Krok 5: Přiřazení role správce vaší aplikaci

Samotné udělení rozsahů nestačí — koncové body rozhraní Okta Management API (např. /api/v1/users) tiše vrátí prázdnou odpověď 200 [], pokud aplikace nemá žádnou roli správce. Musíte přiřadit alespoň Read-Only Administrator:

V konzoli Admin Console přejděte na Zabezpečení > Administrators (nebo na Applications > Applications > vaše aplikace > Admin roles).
Klikněte na Add administrator assignment a vyberte svou aplikaci API Services.

Přiřaďte roli Read-Only Administrator (nebo vyšší, podle potřebných rozsahů).
Klikněte na Uložit.

Bez role správce volání API proběhnou úspěšně s odpovědí 200 OK, ale vrátí prázdné výsledky a neexistuje žádná chyba 403, která by na problém upozornila.

Krok 6: Zadání přihlašovacích údajů v Living Security Platform

Jakmile máte své ID klienta, Privátní klíč (JWK), Doménu Okta a Rozsahy:

Otevřete formulář, ve kterém se potřebujete autentizovat v Okta (Client Credentials).
Zadejte své ID klienta.
Vložte svůj Privátní klíč (JWK) — celý objekt JSON ze skriptu výše (jednořádkový nebo formátovaný).
Zadejte svou Doménu Okta pouze jako subdoménu tenanta (např. dev-12345678).
Zadejte Rozsahy jako seznam oddělený mezerami (např. okta.users.read okta.logs.read).
Formulář odešlete a autentizace by měla proběhnout úspěšně.

Nyní jste připojeni k Okta (Client Credentials).

Části této dokumentace jsou převzaty a upraveny z Nango a používány na základě Elastic License 2.0.

Integrace