> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Okta-integraation käyttöönotto

> Yhdistä Okta Living Security -palveluun käyttäjien elinkaaren, todennuksen, MFA:n ja hallinnollisen toiminnan tietojen hyödyntämiseksi.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Aiheeseen liittyvät resurssit</h2>
    <ul>
      <li>
        <a href="/fi/signals/data-sources">Lue, miten integraatioiden data muuttuu Human Risk Management -signaaleiksi</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Tutustu Living Securityn integraatioihin</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Avaa Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Pyydä Living Securityn demo</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Lisää kaikki neljä Living Securityn synkronoinnin lähtevän liikenteen IP-osoitetta</strong> sallittujen luetteloon kohteessa{' '}
    {system}. Syötä kukin yksittäisenä isäntänä ja lisää perään <code>/32</code>, jos {system} edellyttää CIDR-merkintää:
    <br />
    <code>52.34.139.153/32</code>, <code>54.69.127.183/32</code>, <code>44.247.133.183/32</code>,{' '}
    <code>52.26.211.56/32</code>
    <br />
    <br />
    Liikenne voi lähteä mistä tahansa näistä neljästä osoitteesta, joten vain osan lisääminen sallittujen luetteloon aiheuttaa ajoittaisia
    synkronointivirheitä. Nämä neljä osoitetta ovat samat kaikilla Living Securityn alueilla. Katso{' '}
    <a href="/fi/integrations/managing/egress-ip-addresses">
      Integraatioiden lähtevän liikenteen IP-osoitteiden määrittäminen
    </a>{' '}
    täydellistä luetteloa, muutoskäytäntöä ja vianmääritystä varten.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Syötä tunnistetiedot Living Security Platformissa">
    <p>
      Tämän vaiheen suorittaa henkilö, jolla on Living Securityn käyttöoikeus – ohjelman omistaja tai
      järjestelmänvalvoja, jos hänet on kutsuttu (delegoitu käyttöönotto).
    </p>
    <ol>
      <li>
        Siirry kohtaan <strong>Asetukset → Integraatiot → Luettelo</strong>, etsi{' '}
        <strong>{tile}</strong>-kortti ja valitse <strong>Liitä</strong>.
      </li>
      <li>
        Täytä alla olevat kentät ja valitse sitten <strong>Liitä</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Yleiskatsaus

Okta voi tuottaa normalisoitua tietoa käyttäjien elinkaaresta, todennuksesta, MFA:sta ja hallinnollisesta toiminnasta. Tarkastettuja esimerkkejä ovat:

* `account.locked` — tili lukittu
* `mfa.factor.activated` — ottaa käyttöön lisää MFA-tekijöitä
* `auth.login.failed` — kirjautuminen epäonnistuu

Molemmat yhteystavat lukevat samat kaksi virtaa: käyttäjähakemiston (`/api/v1/users`) ja järjestelmälokin (`/api/v1/logs`). Katso [miten integraatioiden tiedoista muodostuu signaaleja](/fi/signals/data-sources).

## Yhteystavan valinta

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Tunniste | Admin Consolessa luotava API-tunnus | Luomasi ja rekisteröimäsi asiakastunnus ja yksityinen JWK |
| Käyttöönotto | Kolme vaihetta, ei luotavaa avainmateriaalia | Yhdeksän vaihetta, mukaan lukien RSA-avainpari |
| Vaadittava ylläpitäjän rooli | Vain luku -oikeuksilla varustettu ylläpitäjä, määritetään tunnuksen omistajalle | Vain luku -oikeuksilla varustettu ylläpitäjä, määritetään sovellukselle |
| Tunnuksen voimassaolo | Deaktivoituu 30 päivän käyttämättömyyden jälkeen | Ei vanhene; avainparin kierrätys on omalla vastuullasi |
| Käytä, kun | Tämä on suositeltu vaihtoehto useimmille organisaatioille | Tietoturvakäytäntösi kieltää pitkäikäiset API-tunnukset |

Molemmat tavat vaativat saman käyttöoikeuden, joten valinta koskee tunnistetietojen käsittelyä eikä sitä, mitä alusta voi lukea.

***

## Vaihtoehto A — API-tunnus (SSWS)

*Suositeltu.*

### Mitä Living Security tarvitsee

| Tunniste | Kuvaus |
| - | - |
| **API-avain** | Okta API -tunnus. Yhdistämisikkunassa tämän kentän nimi on **API-avain** |
| **Vuokraajan aliverkkotunnus** | `<tenant>` osoitteessa `<tenant>.okta.com` — pelkkä aliverkkotunnus, ei koko URL-osoitetta |

### Edellytykset

* Sinulla on oltava Oktassa **Super Administrator** -rooli, jotta voit luoda palvelutilin käyttäjän, määrittää ylläpitäjärooleja ja luoda API-tunnuksia.

<Steps>
  <Step title="Luo tunnuksen omistava käyttäjä">
    Okta API -tunnus perii sen luoneen käyttäjän oikeudet, ja se lakkaa toimimasta, jos kyseinen käyttäjä deaktivoidaan. Luo erillinen palvelutili henkilökohtaisen ylläpitäjätilin käyttämisen sijaan, jotta yhteys säilyy henkilöstömuutosten yli.

    1. Siirry Admin Consolessa kohtaan **Directory** → **People**.
    2. Valitse **Add person** ja luo käyttäjä, esimerkiksi `svc-livingsecurity@yourcompany.com`.
    3. Aktivoi tili.
  </Step>

  <Step title="Määritä vain luku -oikeuksilla varustettu ylläpitäjärooli">
    Alusta vain lukee tietoja. Laajempien kuin lukuoikeuksien myöntäminen antaa tunnukselle oikeuksia, joita se ei koskaan käytä.

    1. Siirry kohtaan **Security** → **Administrators**.
    2. Valitse **Add administrator** ja valitse edellisessä vaiheessa luotu käyttäjä.
    3. Määritä rooli **Read-only Administrator**.
    4. Tallenna.

    <Note>
      Ilman ylläpitäjäroolia Okta Management API -kutsut onnistuvat vastauksella `200 OK` ja palauttavat tyhjän luettelon. Mikään `403` ei ilmaise, että rooli puuttuu — virrat vain pysyvät tyhjinä.
    </Note>
  </Step>

  <Step title="Luo API-tunnus">
    1. Kirjaudu Admin Consoleen **vaiheessa 1 luotuna palvelutilin käyttäjänä**. Tunnus perii sen tilin oikeudet, jolla se luodaan.
    2. Siirry kohtaan **Security** → **API** ja avaa **Tokens**-välilehti.
    3. Valitse **Create token**, anna tunnukselle nimi, esimerkiksi `Living Security Platform`, ja valitse **Create token**.
    4. Kopioi tunnuksen arvo nyt — Okta näyttää sen vain kerran.

    <Warning>
      Okta deaktivoi API-tunnuksen **30 päivän käyttämättömyyden** jälkeen. Tämän integraation synkronoinnit suoritetaan vähintään kerran päivässä, joten toimiva yhteys pitää oman tunnuksensa aktiivisena. Kuukauden ajan keskeytettynä ollut yhteys tarvitsee uuden tunnuksen.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Yllä oleva osoiteluettelo on merkityksellinen vain, jos Okta-organisaatiosi rajoittaa API-käyttöä **verkkovyöhykkeen** perusteella. Useimmissa organisaatioissa näin ei ole.
    </Note>
  </Step>

  <Step title="Selvitä vuokraajan aliverkkotunnus">
    Admin Consolen URL-osoite on muotoa `https://acme-admin.okta.com`. Vuokraajan aliverkkotunnus on `acme` — ilman `-admin`-päätettä, ilman `.okta.com` ja ilman `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Kenttä | Arvo |
    | - | - |
    | **API-avain** | Vaiheessa 3 luotu API-tunnus |
    | **Vuokraajan aliverkkotunnus** | Vaiheessa 4 selvitetty aliverkkotunnus (esim. `acme`) |
  </ConnectInPlatform>
</Steps>

Yhteys Oktaan (SSWS) on nyt muodostettu.

### Vianmääritys

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Tunnus on virheellinen, se on peruutettu tai se on deaktivoitu 30 päivän käyttämättömyyden jälkeen. Luo uusi tunnus palvelutilin käyttäjänä ja syötä se yhteyteen uudelleen.
  </Accordion>

  <Accordion title="Yhteys on muodostettu, mutta kaikki virrat ovat tyhjiä">
    Tunnuksen omistajalla ei ole ylläpitäjärooli. Määritä palvelutilille **Read-only Administrator** (vaihe 2) — kun rooli puuttuu, API palauttaa `200 OK` ja tyhjän luettelon virheen sijaan.
  </Accordion>

  <Accordion title="Synkronoinnit epäonnistuvat henkilöstömuutoksen jälkeen">
    Tunnus lakkaa toimimasta, jos sen luonut käyttäjä deaktivoidaan. Tästä syystä tunnuksen tulee kuulua palvelutilille eikä henkilölle.
  </Accordion>
</AccordionGroup>

***

## Vaihtoehto B — OAuth 2.0 -palvelusovellus

Käytä tätä tapaa, kun tietoturvakäytäntösi ei salli pitkäikäisiä API-tunnuksia. Se korvaa tunnuksen asiakastunnuksella ja omistamallasi RSA-avainparilla. Alustassa tämä on **Okta (OAuth 2.0)** -ruutu kohdassa **Asetukset → Integraatiot → Luettelo**.

Todennus Oktaan Client Credentials -menetelmällä edellyttää seuraavia tietoja:

1. **Client ID** (asiakastunnus) - Okta API Services -sovelluksesi yksilöivä tunniste.
2. **Private Key (JWK)** - RSA-yksityisavain JSON Web Key -muodossa, jonka julkinen avain on rekisteröity Okta-sovellukseesi.
3. **Okta Domain** - Vain Okta-vuokraajasi aliverkkotunnus (esim. `dev-12345678`), ei koko isäntänimeä.
4. **Scopes** - Välilyönnein erotettu luettelo Okta Management API -oikeuksista (esim. `okta.users.read okta.logs.read`).

Tämä ohje opastaa luomaan Oktassa API Services -sovelluksen, jossa käytetään `private_key_jwt`-todennusta.

### Edellytykset:

* Sinulla on oltava Okta-tili. Voit rekisteröidä maksuttoman kehittäjätilin osoitteessa [developer.okta.com](https://developer.okta.com/signup/).

#### Vaihe 1: Okta API Services -sovelluksen luominen

1. Kirjaudu [Okta Admin Consoleen](https://login.okta.com/).
2. Siirry vasemman reunan valikossa kohtaan **Applications** > **Applications**.
3. Valitse **Create App Integration**.
4. Valitse kirjautumistavaksi **API Services** ja valitse **Seuraava**.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/select-api-service.png" style={{maxWidth: "550px"}} />

5. Anna sovellukselle nimi ja valitse **Tallenna**.
6. Etsi sovelluksen **General**-välilehdeltä **Client ID** (asiakastunnus) — tarvitset sitä viimeisessä vaiheessa.
7. Aseta Client authentication -asetukseksi **Public key / Private key**. `okta.*`-oikeudet tuetaan vain tällä todennustavalla.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/select-public-private-key.png" style={{maxWidth: "550px"}} />

8. Poista **Proof of possession (DPoP)** käytöstä — sitä ei tueta.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/disable-dpop.png" style={{maxWidth: "550px"}} />

<Note>
  Sovellus on luotava tyypillä **API Services**.
</Note>

#### Vaihe 2: RSA-avainparin luominen ja rekisteröinti

##### Okta-avaingeneraattorin käyttö

Okta voi luoda RSA-avainparin puolestasi suoraan Admin Consolessa:

1. Avaa Admin Consolessa API Services -sovelluksesi.
2. Siirry **General**-välilehdelle ja vieritä **PUBLIC KEYS** -osioon.
3. Valitse **Add Key** ja sitten **Generate new key**.
4. Valitse **Tallenna** — Okta luo avainparin ja näyttää **Private Key (JWK)** -yksityisavaimen kerran.
5. Kopioi ja tallenna yksityisavaimen JSON heti — sitä ei näytetä uudelleen.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/create-public-key.png" style={{maxWidth: "550px"}} />

6. Julkinen avain rekisteröidään sovellukseesi automaattisesti.

<Note>
  Kopioi yksityinen JWK ennen ikkunan sulkemista. Liitä se Living Security Platformin **Private Key** -kenttään viimeisessä vaiheessa.
</Note>

##### Oman avaimen luominen

Okta käyttää `private_key_jwt`-menetelmää API Services -sovelluksille. Luot RSA-avainparin, rekisteröit **julkisen** JWK:n Oktaan ja annat **yksityisen** JWK:n Living Security Platformille.

**Luo yksityinen JWK** seuraavalla Node.js-skriptillä (vaatii Node.js 18+):

```javascript theme={null}
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));
```

**Rekisteröi julkinen JWK Oktaan:**

1. Avaa Admin Consolessa API Services -sovelluksesi.
2. Siirry **General**-välilehdelle ja vieritä **PUBLIC KEYS** -osioon.
3. Valitse **Add Key**, liitä yllä olevan skriptin tulostama **julkisen JWK:n JSON** ja valitse **Tallenna**.

<Note>
  Living Security Platformiin liitetään yksityinen JWK. Se sisältää kaiken avainmateriaalin (`d`, `p`, `q`, `dp`, `dq`, `qi`) sekä `kid`. Pidä se salassa.
</Note>

#### Vaihe 3: Okta Domain -arvon selvittäminen

Syötä vain Okta-vuokraajasi aliverkkotunnus — osa ennen `.okta.com`.

* Admin Consolessa selaimen osoiterivillä näkyy URL-osoite, joka on muotoa `https://dev-12345678-admin.okta.com`.
* **Okta Domain** on pelkkä aliverkkotunnus (esim. `dev-12345678`), ei `dev-12345678.okta.com`.
* Vaihtoehtoisesti voit etsiä Okta-verkkotunnuksesi Admin Consolen kohdasta **Settings** > **Account** ja käyttää siitä aliverkkotunnusosaa.

#### Vaihe 4: API-oikeuksien myöntäminen sovellukselle

Okta edellyttää vähintään yhtä oikeutta (scope) jokaisessa tunnuspyynnössä. Ennen kuin sovelluksesi voi pyytää tiettyjä oikeuksia, ne on myönnettävä:

1. Siirry Admin Consolessa kohtaan **Applications** > **Applications** ja avaa sovelluksesi.
2. Valitse **Okta API Scopes** -välilehti.
3. Myönnä integraatiosi tarvitsemat oikeudet: `okta.users.read` ja `okta.logs.read`.

Täydellinen luettelo käytettävissä olevista oikeuksista on [Okta Management API -viitteessä](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Vaihe 5: Ylläpitäjäroolin määrittäminen sovellukselle

Pelkkä oikeuksien myöntäminen ei riitä — Okta Management API -päätepisteet (esim. `/api/v1/users`) palauttavat äänettömästi tyhjän `200 []`-vastauksen, jos sovelluksella ei ole ylläpitäjäroolia. Sinun on määritettävä vähintään **Read-Only Administrator**:

1. Siirry Admin Consolessa kohtaan **Security** > **Administrators** (tai kohtaan **Applications** > **Applications** > sovelluksesi > **Admin roles**).
2. Valitse **Add administrator assignment** ja valitse API Services -sovelluksesi.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/admin-role-dropdown.png" style={{maxWidth: "550px"}} />

3. Määritä rooli **Read-Only Administrator** (tai laajempi tarvitsemistasi oikeuksista riippuen).
4. Valitse **Tallenna**.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/add-admin-role.png" style={{maxWidth: "550px"}} />

<Note>
  Ilman ylläpitäjäroolia API-kutsut onnistuvat vastauksella `200 OK` mutta palauttavat tyhjiä tuloksia, eikä ongelmasta kerro mikään `403`-virhe.
</Note>

#### Vaihe 6: Tunnistetietojen syöttäminen Living Security Platformiin

Kun sinulla on **Client ID** (asiakastunnus), **Private Key (JWK)**, **Okta Domain** ja **Scopes**:

1. Avaa lomake, jossa todennus Oktaan (Client Credentials) tehdään.
2. Syötä **asiakastunnus**.
3. Liitä **Private Key (JWK)** — koko JSON-objekti yllä olevasta skriptistä (yhdellä rivillä tai muotoiltuna).
4. Syötä **Okta Domain** pelkkänä vuokraajan aliverkkotunnuksena (esim. `dev-12345678`).
5. Syötä **Scopes** välilyönnein erotettuna luettelona (esim. `okta.users.read okta.logs.read`).
6. Lähetä lomake, ja todennuksen pitäisi onnistua.

Yhteys Oktaan (Client Credentials) on nyt muodostettu.

***

<Note>Osia tästä dokumentaatiosta on mukautettu [Nango](https://nango.dev/docs/)-dokumentaatiosta, ja niitä käytetään [Elastic License 2.0](https://github.com/NangoHQ/nango?tab=License-1-ov-file#readme) -lisenssin mukaisesti.</Note>

<PublicIntegrationNextSteps />


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.