Az Okta integráció beállítása

Áttekintés

Az Okta normalizált adatokkal járulhat hozzá a felhasználói életciklus, a hitelesítés, az MFA és az adminisztratív tevékenység területén. Az áttekintett példák a következők:

account.locked — fiók zárolva
mfa.factor.activated — további MFA-tényezőket aktivál
auth.login.failed — a bejelentkezés sikertelen

Mindkét csatlakozási módszer ugyanazt a két adatfolyamot olvassa: a felhasználói címtárat (/api/v1/users) és a rendszernaplót (/api/v1/logs). Lásd: hogyan válnak az integrációs adatokból jelzések.

Csatlakozási módszer kiválasztása

	Okta (SSWS)	Okta (OAuth 2.0)
Hitelesítő adat	Az Admin Console felületen létrehozott API-token	Ön által generált és regisztrált ügyfél-azonosító és privát JWK
Beállítás	Három lépés, kulcsanyagot nem kell generálni	Kilenc lépés, köztük egy RSA-kulcspár létrehozása
Szükséges rendszergazdai szerepkör	Csak olvasási jogú rendszergazda, a token tulajdonosához rendelve	Csak olvasási jogú rendszergazda, az alkalmazáshoz rendelve
Token élettartama	30 nap használat nélkül inaktiválódik	Nem jár le; a kulcspár cseréje az Ön feladata
Mikor használja	Ez a legtöbb szervezet számára ajánlott megoldás	Biztonsági szabályzata tiltja a hosszú élettartamú API-tokenek használatát

Mindkét módszerhez ugyanarra a hozzáférésre van szükség, ezért a választás a hitelesítő adatok kezelésére vonatkozik, nem arra, hogy a platform mit olvashat.

A lehetőség — API-token (SSWS)

Ajánlott.

A Living Security számára szükséges adatok

Hitelesítő adat	Leírás
API-kulcs	Egy Okta API-token. A csatlakozási párbeszédpanel ezt a mezőt API-kulcs néven jeleníti meg
Bérlői aldomain	A `<tenant>` a `<tenant>.okta.com` címben — csak az aldomain, nem a teljes URL

Előfeltételek

Az Okta Super Administrator szerepkörével kell rendelkeznie ahhoz, hogy szolgáltatásfiók-felhasználót hozzon létre, rendszergazdai szerepköröket rendeljen hozzá, és API-tokeneket hozzon létre.

Felhasználó létrehozása a token tulajdonosaként

Az Okta API-token annak a felhasználónak a jogosultságait hordozza, aki létrehozta, és leáll, ha ezt a felhasználót inaktiválják. Személyes rendszergazdai fiók helyett hozzon létre külön szolgáltatásfiókot, hogy a kapcsolat a személyi változásokat is túlélje.

Az Admin Console felületen lépjen a Directory → People oldalra.
Kattintson az Add person elemre, és hozzon létre egy felhasználót, például svc-livingsecurity@yourcompany.com néven.
Aktiválja a fiókot.

A csak olvasási jogú rendszergazdai szerepkör hozzárendelése

A platform kizárólag olvas. Az olvasásnál szélesebb körű hozzáférés megadása olyan jogosultságokat adna a tokennek, amelyeket soha nem használ.

Lépjen a Security → Administrators oldalra.
Kattintson az Add administrator elemre, és válassza ki az előző lépésben létrehozott felhasználót.
Rendelje hozzá a Read-only Administrator szerepkört.
Save.

Rendszergazdai szerepkör nélkül az Okta Management API hívásai 200 OK válaszkóddal sikeresek, és üres listát adnak vissza. Nincs 403, amely jelezné a szerepkör hiányát — az adatfolyamok egyszerűen üresek maradnak.

Az API-token létrehozása

Jelentkezzen be az Admin Console felületre az 1. lépésben létrehozott szolgáltatásfiók-felhasználóként. A token annak a fióknak a jogosultságait örökli, amelyik létrehozza.
Lépjen a Security → API oldalra, és nyissa meg a Tokens lapot.
Kattintson a Create token elemre, adjon neki nevet, például Living Security Platform, majd kattintson a Create token elemre.
Másolja ki a token értékét most — az Okta csak egyszer jeleníti meg.

Az Okta 30 nap használat nélkül inaktivál egy API-tokent. Az integráció szinkronizálásai legalább naponta egyszer lefutnak, ezért az aktív kapcsolat életben tartja a saját tokenjét. Az egy hónapig szüneteltetett kapcsolathoz új token szükséges.

A fenti címlista csak akkor számít, ha az Okta-szervezete hálózati zónák alapján korlátozza az API-hozzáférést. A legtöbb szervezet nem így tesz.

A bérlői aldomain megkeresése

Az Admin Console URL-je így néz ki: https://acme-admin.okta.com. A bérlői aldomain a acme — a -admin utótag, a .okta.com és a https:// nélkül.

Ezzel csatlakozott az Okta (SSWS) szolgáltatáshoz.

Hibaelhárítás

401 Unauthorized

A token érvénytelen, visszavonták, vagy 30 nap inaktivitás után inaktiválták. Hozzon létre új tokent a szolgáltatásfiók-felhasználóként, és adja meg újra a kapcsolaton.

A kapcsolat létrejött, de minden adatfolyam üres

A token tulajdonosának nincs rendszergazdai szerepköre. Rendelje hozzá a Read-only Administrator szerepkört a szolgáltatásfiókhoz (2. lépés) — ha a szerepkör hiányzik, az API hiba helyett 200 OK választ ad üres listával.

A szinkronizálás személyi változás után sikertelen

A token leáll, ha a létrehozó felhasználót inaktiválják. Ezért a tokennek szolgáltatásfiókhoz kell tartoznia, nem természetes személyhez.

B lehetőség — OAuth 2.0 szolgáltatásalkalmazás

Akkor használja ezt a módszert, ha a biztonsági szabályzata nem engedélyezi a hosszú élettartamú API-tokeneket. A tokent egy ügyfél-azonosítóval és egy Ön által birtokolt RSA-kulcspárral váltja fel. A platformon ez az Okta (OAuth 2.0) csempe a beállítások → integrációk → katalógus alatt. Az Okta Client Credentials használatával történő hitelesítéshez a következőkre van szükség:

Ügyfél-azonosító - Az Okta API Services alkalmazás egyedi azonosítója.
Privát kulcs (JWK) - A JSON Web Key formátumú RSA privát kulcs, amelynek nyilvános kulcsa regisztrálva van az Okta alkalmazásban.
Okta-tartomány - Csak az Okta-bérlő aldomainje (pl. dev-12345678), nem a teljes hosztnév.
Hatókörök - Az Okta Management API hatóköreinek szóközzel elválasztott listája (pl. okta.users.read okta.logs.read).

Ez az útmutató végigvezeti egy API Services alkalmazás létrehozásán az Oktában private_key_jwt hitelesítéssel.

Előfeltételek:

Rendelkeznie kell Okta-fiókkal. Ingyenes fejlesztői fiókra a developer.okta.com oldalon regisztrálhat.

1. lépés: Az Okta API Services alkalmazás létrehozása

Jelentkezzen be az Okta Admin Console felületre.
A bal oldali sávban lépjen az Applications > Applications oldalra.
Kattintson a Create App Integration elemre.
Bejelentkezési módként válassza az API Services lehetőséget, majd kattintson a Next elemre.

Adjon nevet az alkalmazásnak, majd kattintson a Save elemre.
Az alkalmazás General lapján keresse meg a Client ID értéket — az utolsó lépésben szüksége lesz rá.
A Client authentication beállításnál válassza a Public key / Private key lehetőséget. A okta.* hatókörök csak ezzel a hitelesítési móddal támogatottak.

Tiltsa le a Proof of possession (DPoP) beállítást — nem támogatott.

Az alkalmazást API Services típusúként kell létrehozni.

2. lépés: Az RSA-kulcspár generálása és regisztrálása

Az Okta kulcsgenerátorának használata

Az Okta közvetlenül az Admin Console felületen is létre tudja hozni az RSA-kulcspárt:

Az Admin Console felületen nyissa meg az API Services alkalmazást.
Lépjen a General lapra, és görgessen a PUBLIC KEYS szakaszhoz.
Kattintson az Add Key elemre, majd válassza a Generate new key lehetőséget.
Kattintson a Save elemre — az Okta létrehozza a kulcspárt, és egyszer megjeleníti a Private Key (JWK) értéket.
Azonnal másolja ki és mentse el a privát kulcs JSON-ját — nem jelenik meg újra.

A nyilvános kulcs automatikusan regisztrálódik az alkalmazásban.

A párbeszédpanel bezárása előtt másolja ki a privát JWK-t. Az utolsó lépésben illessze be a Living Security Platform Privát kulcs mezőjébe.

Saját kulcs létrehozása

Az Okta API Services alkalmazásokhoz private_key_jwt használ. Létrehoz egy RSA-kulcspárt, regisztrálja a nyilvános JWK-t az Oktában, a privát JWK-t pedig megadja a Living Security Platformnak. Privát JWK generálása az alábbi Node.js szkripttel (Node.js 18+ szükséges):

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));

A nyilvános JWK regisztrálása az Oktában:

Az Admin Console felületen nyissa meg az API Services alkalmazást.
Lépjen a General lapra, és görgessen a PUBLIC KEYS szakaszhoz.
Kattintson az Add Key elemre, illessze be a fenti szkript által kiadott nyilvános JWK JSON-t, majd kattintson a Save elemre.

A privát JWK-t kell beillesztenie a Living Security Platformba. Tartalmazza az összes kulcsanyagot (d, p, q, dp, dq, qi) és a kid értéket. Tartsa titokban.

3. lépés: Az Okta-tartomány megkeresése

Csak az Okta-bérlő aldomainjét adja meg — a .okta.com előtti részt.

Az Admin Console felületen a böngésző címsorában egy ilyen URL látható: https://dev-12345678-admin.okta.com.
Az Okta-tartomány csak az aldomain (pl. dev-12345678), nem a dev-12345678.okta.com.
Másik lehetőségként az Admin Console felületen lépjen a Settings > Account oldalra, ahol megtalálja az Okta-tartományt, majd használja az aldomain részt.

4. lépés: API-hatókörök megadása az alkalmazásnak

Az Okta minden tokenkérésben legalább egy hatókört megkövetel. Mielőtt az alkalmazás adott hatóköröket kérhetne, azokat meg kell adni:

Az Admin Console felületen lépjen az Applications > Applications oldalra, és nyissa meg az alkalmazást.
Kattintson az Okta API Scopes lapra.
Adja meg az integrációhoz szükséges hatóköröket: okta.users.read és okta.logs.read.

Az elérhető hatókörök teljes listája az Okta Management API referenciában található.

5. lépés: Rendszergazdai szerepkör hozzárendelése az alkalmazáshoz

A hatókörök megadása önmagában nem elegendő — az Okta Management API végpontjai (pl. /api/v1/users) néma módon üres 200 [] választ adnak, ha az alkalmazásnak nincs rendszergazdai szerepköre. Legalább a Read-Only Administrator szerepkört hozzá kell rendelnie:

Az Admin Console felületen lépjen a Security > Administrators oldalra (vagy az Applications > Applications > az Ön alkalmazása > Admin roles oldalra).
Kattintson az Add administrator assignment elemre, és válassza ki az API Services alkalmazást.

Rendelje hozzá a Read-Only Administrator szerepkört (vagy magasabbat, a szükséges hatóköröktől függően).
Kattintson a Save elemre.

Rendszergazdai szerepkör nélkül az API-hívások 200 OK válaszkóddal sikeresek, de üres eredményt adnak, és nincs 403 hiba, amely jelezné a problémát.

6. lépés: Hitelesítő adatok megadása a Living Security Platformban

Ha már rendelkezik az ügyfél-azonosítóval, a privát kulccsal (JWK), az Okta-tartománnyal és a hatókörökkel:

Nyissa meg az űrlapot, amelyen az Okta (Client Credentials) hitelesítést el kell végeznie.
Adja meg az ügyfél-azonosítót.
Illessze be a privát kulcsot (JWK) — a fenti szkript által kiadott teljes JSON-objektumot (egysoros vagy formázott alakban).
Adja meg az Okta-tartományt csak bérlői aldomainként (pl. dev-12345678).
Adja meg a hatóköröket szóközzel elválasztott listaként (pl. okta.users.read okta.logs.read).
Küldje el az űrlapot, és a hitelesítésnek sikeresnek kell lennie.

Ezzel csatlakozott az Okta (Client Credentials) szolgáltatáshoz.

A dokumentáció egyes részei a Nango anyagából készült adaptációk, az Elastic License 2.0 feltételei szerint felhasználva.

Integrációk

Integráció beállítása

Katalógus

Kimenő csatornák

Áttekintés

Csatlakozási módszer kiválasztása

A lehetőség — API-token (SSWS)