> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/admin-settings/authentication-and-user-provisioning/sso-setup-guide.md).

# veiledningen for SSO-oppsett

Single Sign-On lar brukerne dine logge inn på CERRIX med sin eksisterende organisatoriske identitet — den samme kontoen de bruker til Microsoft 365, Okta eller en hvilken som helst annen tilkoblet tjeneste. Når SSO er aktivert, trenger brukerne ikke lenger et separat CERRIX-passord, og de autentiseres gjennom din egen identitetsleverandør.

Denne veiledningen tar deg gjennom alt du trenger å forberede før du ber CERRIX-teamet om å aktivere SSO. Alle konfigurasjonstrinnene skjer i ditt eget miljø; CERRIX utfører den endelige aktiveringen på vår side når du sender inn forespørselen din.

{% hint style="info" %}
CERRIX støtter **Microsoft Entra ID (Azure AD)** og **Okta** rett ut av boksen. Hvis organisasjonen din bruker en annen identitetsleverandør, ta kontakt med din CERRIX-kontaktperson for å diskutere alternativer.
{% endhint %}

***

### Før du begynner

Du trenger:

* **Administratortilgang** til identitetsleverandøren din (Microsoft Entra ID- eller Okta-administrasjonskonsollen).
* **URL-en til CERRIX-miljøet ditt** — adressen du bruker for å få tilgang til CERRIX, for eksempel `acme.cerrix.com`. Du trenger dette for å sette sammen redirect URI-en. Hvert trinn i denne veiledningen som involverer en URL, krever ditt eget underdomene. Ikke kopier URL-er fra denne veiledningen uten først å erstatte underdomenet ditt.
* En måte å ta et **skjermbilde** av den fullførte konfigurasjonen for redirect URI-en, som du skal ta med i aktiveringsforespørselen din.

***

### Slik fungerer SSO i CERRIX

Når en bruker klikker på **Arbeidskonto** på innloggingssiden, omdirigerer CERRIX nettleseren deres til innloggingssiden til identitetsleverandøren din. Etter at brukeren har autentisert seg, sender identitetsleverandøren et sikkert token tilbake til CERRIX, som verifiserer det og oppretter en sesjon. Brukeren skriver aldri inn et CERRIX-spesifikt passord.

CERRIX bruker **OpenID Connect (OIDC)** protokollen med **PKCE** (Proof Key for Code Exchange)-flyten. Dette er gjeldende bransjestandard for nettleserbaserte applikasjoner og er den eneste støttede konfigurasjonen for nye SSO-oppsett.

#### Stille innlogging

Hvis organisasjonen din ikke bruker det standard CERRIX-innloggingsskjemaet, kan CERRIX konfigureres til automatisk å starte SSO-innloggingen når innloggingssiden lastes inn — uten at brukeren trenger å klikke på noe. Dette gir en sømløs opplevelse der navigering til CERRIX-miljøet ditt sender brukerne direkte til identitetsleverandøren din.

Stille innlogging er aktivert som standard når standard innloggingsskjema er deaktivert. Hvis du vil ha stille innlogging aktivert sammen med standardskjemaet, oppgi dette i aktiveringsforespørselen din.

***

### Slik setter du opp redirect URI-en din

I konfigurasjonstrinnene nedenfor må du angi en **redirect URI** — adressen identitetsleverandøren sender brukerne tilbake til etter autentisering. Redirect URI-en din er alltid:

```
https://[your-subdomain].cerrix.com/auth/callback
```

Erstatt `[your-subdomain]` med underdomenet til CERRIX-miljøet ditt. For eksempel:

| Din CERRIX-URL          | Din redirect URI                              |
| ----------------------- | --------------------------------------------- |
| `acme.cerrix.com`       | `https://acme.cerrix.com/auth/callback`       |
| `globalcorp.cerrix.com` | `https://globalcorp.cerrix.com/auth/callback` |

{% hint style="warning" %}
Redirect URI-en må stemme nøyaktig med miljøet ditt. En uoverensstemmelse er den vanligste årsaken til at SSO-aktivering mislykkes. Dobbeltsjekk at du har brukt ditt eget underdomene og ikke et eksempel fra denne veiledningen.
{% endhint %}

***

### Microsoft Entra ID (Azure AD)

#### 1. Registrer en ny applikasjon

1. Logg inn på [Azure-portalen](https://portal.azure.com/) og åpne **Microsoft Entra ID**.
2. I menyen til venstre velger du **App-registreringer**, og klikk deretter på **Ny registrering**.
3. Gi applikasjonen et gjenkjennelig navn, for eksempel `CERRIX SSO`.
4. Under **Støttede kontotyper**, velg **Kontoer i bare denne organisasjonskatalogen**.
5. La **Redirect URI** feltet stå tomt foreløpig — du konfigurerer det i neste trinn.
6. Klikk **Registrer**.

#### 2. Konfigurer redirect URI-en

Det er avgjørende å konfigurere redirect URI-en riktig. Plattformtypen du velger, bestemmer autentiseringsflyten; hvis du velger feil type, vil SSO ikke fungere.

1. I den nylig registrerte applikasjonen din går du til **Autentisering** i menyen til venstre.
2. Under **Plattformkonfigurasjoner**, klikk **Legg til en plattform**.
3. Velg **Enkeltsideapplikasjon (SPA)**.

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Å velge <strong>Enkeltsideapplikasjon</strong> er viktig. Denne plattformtypen aktiverer PKCE automatisk og kreves for CERRIX SSO-oppsettet. Ikke velg "Web" — den plattformen bruker en annen flyt som ikke er kompatibel.</p></div>
4. I **Redirect URI-er** feltet, skriver du inn redirect URI-en din ved å bruke **ditt eget underdomene**:

   ```
   https://[your-subdomain].cerrix.com/auth/callback
   ```
5. Klikk **Konfigurer**.

#### 3. Verifiser innstillinger for implicit grant

Med SPA-plattformen og PKCE hentes tilgangs- og ID-tokener sikkert gjennom autorisasjonskodeutvekslingen. De eldre alternativene for implicit grant bør forbli deaktivert.

1. Fortsatt i **Autentisering**, bla til **Implicit grant og hybride flyter**.
2. Sørg for at både **Tilgangstokener** og **ID-tokener** er **ikke avkrysset**.
3. Klikk **Lagre** hvis du gjorde noen endringer.

#### 4. Konfigurer API-tillatelser

CERRIX trenger **User.Read** tillatelsen på Microsoft Graph for å identifisere den innloggede brukeren. Hvis du gir administrativt samtykke på leietakernivå, slipper brukerne å bli bedt om dette individuelt ved første innlogging.

1. I app-registreringen din velger du **API-tillatelser** i menyen til venstre.
2. Den **User.Read** delegerte tillatelsen under **Microsoft Graph** legges til som standard. Hvis den mangler, klikker du på **Legg til en tillatelse → Microsoft Graph → Delegerte tillatelser**, søk etter **User.Read**, og legg den til.
3. Øverst i tillatelseslisten klikker du på **Gi administrativt samtykke for \[navnet på leietakeren din]**.
4. Bekreft med **Ja**. **Status** kolonnen skal endres til **Gitt for \[navnet på leietakeren din]** med en grønn hake ved siden av **User.Read**.

{% hint style="warning" %}
Den **Gi administrativt samtykke** knappen er bare synlig for brukere med riktig Entra ID-rolle (vanligvis Global Administrator eller Privileged Role Administrator). Hvis du ikke ser knappen, ber du leietakeradministratoren din utføre dette trinnet.
{% endhint %}

#### 5. Slik identifiserer CERRIX brukerne dine

Etter autentisering utsteder Entra ID et **ID-token** — et signert dokument som inneholder claims om brukeren. CERRIX leser **`preferred_username`** claimet fra dette tokenet for å matche den innloggede brukeren med en CERRIX-konto. I Entra ID, `preferred_username` inneholder brukerens **UPN (User Principal Name)** — vanligvis e-postadressen som brukes til å logge inn, for eksempel `john@acme.com`. Se [Microsofts referanse for ID-token-claims](https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference#payload-claims) for fullstendig liste over standard claims og verdiene deres.

{% hint style="warning" %}
`preferred_username` (UPN) er ikke det samme som brukerens **visningsnavn**. `navn` claimet inneholder visningsnavnet (for eksempel `John Doe`), mens `preferred_username` inneholder innloggingsnavnet (`john@acme.com`). Sørg for at **AD-innlogging** feltet på CERRIX-brukerpostene dine er fylt ut med UPN-en, ikke visningsnavnet — ellers vil innlogginger mislykkes selv om autentiseringen lykkes.
{% endhint %}

Hvis UPN-en ikke samsvarer med **AD-innlogging** som er lagret på brukerposten i CERRIX, kan du legge til en valgfri claim i ID-tokenet slik at CERRIX leser en annen verdi.

**Legg til en valgfri claim**

1. I app-registreringen din går du til **Token-konfigurasjon** i menyen til venstre.
2. Klikk **Legg til valgfri claim**, velg **ID** som token-type, og velg claimet du vil at CERRIX skal bruke — for eksempel `email` eller `upn`.
3. Klikk **Legg til**. Hvis Entra ID ber om at claimet krever flere Microsoft Graph-tillatelser, bekreft for å legge dem til.
4. Gå til **API-tillatelser** og klikk **Gi administrativt samtykke for \[navnet på leietakeren din]** for å samtykke til eventuelle nylig lagt til tillatelser.

Når du sender inn aktiveringsforespørselen din, ta med navnet på claimet slik at CERRIX kan konfigureres til å lese det fra ID-tokenet i stedet for `preferred_username`.

{% hint style="warning" %}
Claimverdien må samsvare nøyaktig med **AD-innlogging** feltet på brukerposten i CERRIX. Hvis de ikke samsvarer, vil SSO-innloggingen mislykkes selv om Entra ID-autentiseringen lykkes.
{% endhint %}

#### 6. Samle inn den nødvendige informasjonen

1. I app-registreringen din går du til **Oversikt**.
2. Noter **Program-ID (klient-ID)** — en GUID som unikt identifiserer app-registreringen din i CERRIX.
3. Noter **Katalog-ID (leietaker-ID)** — en GUID som identifiserer Azure-organisasjonen din.
4. Hvis du har konfigurert en valgfri claim, noter claimnavnet.

#### 7. Ta et skjermbilde

Før du sender inn forespørselen din, ta et skjermbilde av **Autentisering** siden som tydelig viser redirect URI-en du konfigurerte under **Enkeltsideapplikasjon**. Du legger dette ved aktiveringsforespørselen din.

***

### Okta

#### 1. Opprett en ny appintegrasjon

1. Logg inn på din **Okta Admin Console**.
2. I menyen til venstre går du til **Applications → Applications**, og klikk deretter på **Opprett appintegrasjon**.
3. For **Innloggingsmetode**, velg **OIDC – OpenID Connect**.
4. For **Applikasjonstype**, velg **Single-Page Application**, og klikk deretter på **Neste**.

#### 2. Konfigurer applikasjonen

1. Skriv inn et navn for applikasjonen, for eksempel `CERRIX SSO`.
2. Under **Grant type**, sørg for **Authorization Code** er valgt. Okta aktiverer PKCE automatisk for enkeltsideapplikasjoner.

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Du trenger ikke å aktivere noen flere grant-typer. Implicit og client credentials-grants brukes ikke av CERRIX.</p></div>
3. Under **Sign-in redirect URIs**, klikk **Legg til URI** og skriv inn redirect URI-en din ved å bruke **ditt eget underdomene**:

   ```
   https://[your-subdomain].cerrix.com/auth/callback
   ```
4. Under **Sign-out redirect URIs**, skriv inn basis-URL-en for CERRIX-miljøet ditt:

   ```
   https://[your-subdomain].cerrix.com
   ```
5. Under **Assignments**, velg hvem i organisasjonen din som skal ha tilgang. Du kan tildele bestemte grupper eller tillate alle brukere.
6. Klikk **Lagre**.

#### 3. Konfigurer autorisasjonsserveren (valgfritt)

CERRIX fungerer med Okta sin innebygde **standard tilpassede autorisasjonsserver** rett ut av boksen — ingen ekstra konfigurasjon kreves fra din side. Standardserveren er tilgjengelig på `/oauth2/default/` i hver Okta-organisasjon. Du trenger bare denne delen hvis du vil ha en **dedikert** autorisasjonsserver for CERRIX i stedet.

Grunner til at du kanskje foretrekker en dedikert server:

* **Isolasjon av audience.** Tokenene fra standardserveren bruker `api://default` som audience. En dedikert server lar deg sette audience til CERRIX-klient-ID-en din, slik at tokenene som utstedes for CERRIX ikke godtas av andre tjenester som også validerer mot Okta-organisasjonen din.
* **Isolert claim-konfigurasjon.** Hvis andre Okta-tilkoblede applikasjoner deler standardserveren, vil endringer i claim-mappingene påvirke alle. En dedikert server lar deg justere claims for CERRIX uten å påvirke andre applikasjoner.

For å opprette en dedikert autorisasjonsserver:

1. I menyen til venstre utvider du **Security** og velger **API**.
2. På **Authorization Servers** fanen klikker du på **Legg til autorisasjonsserver**.
3. Fyll inn feltene:
   * **Navn**: et gjenkjennelig navn, for eksempel `CERRIX`.
   * **Audience**: lim inn **Client ID** fra appintegrasjonen din.
   * **Beskrivelse**: valgfritt.
4. Klikk **Lagre**.

Noter **Metadata-URI** på serverens **Innstillinger** fane — du tar med denne i aktiveringsforespørselen din.

#### 4. Slik identifiserer CERRIX brukerne dine

Etter autentisering utsteder Okta et **ID-token** — et signert dokument som inneholder claims om brukeren. CERRIX leser **`preferred_username`** claim fra dette tokenet for å matche den innloggede brukeren med en CERRIX-konto. Som standard setter Okta `preferred_username` til `user.login`, som er Okta-innloggingsnavnet (vanligvis e-postadressen som brukes til å logge inn på Okta).

Hvis verdien i `preferred_username` ikke samsvarer med **AD-innlogging** som er lagret på brukerposten i CERRIX, legg til et dedikert claim som returnerer riktig verdi og fortell CERRIX å lese det.

På **Claims** fanen for autorisasjonsserveren din klikker du på **Legg til claim** og konfigurer:

* **Navn**: et hvilket som helst navn, for eksempel `cerrix_username`
* **Inkluder i token-type**: **ID Token**, **Alltid**
* **Verditype**: **Uttrykk**
* **Verdi**: Okta-uttrykket som returnerer den samsvarende verdien — for eksempel `user.email` eller et tilpasset Okta-profilattributt som `user.cerrixUsername`
* **Inkluder i**: **Hvilket som helst scope**

Når du sender inn aktiveringsforespørselen din, ta med navnet på claimet slik at CERRIX kan konfigureres til å lese det fra ID-tokenet i stedet for `preferred_username`.

{% hint style="warning" %}
Uansett hvilket alternativ du velger, må claimverdien samsvare nøyaktig med **AD-innlogging** feltet på brukerposten i CERRIX. Hvis de ikke samsvarer, vil SSO-innloggingen mislykkes selv om Okta-autentiseringen lykkes.
{% endhint %}

#### 5. Samle inn den nødvendige informasjonen

1. Fra appintegrasjonens **Generelt** fane, noter **Client ID**.
2. Noter **Metadata-URI** til autorisasjonsserveren du bruker. Finn den under **Security → API → Authorization Servers → \[your server] → Settings**. For standardserveren ser den slik ut `https://[okta-domain]/oauth2/default/.well-known/openid-configuration`.
3. Hvis du la til et egendefinert claim, noter claimnavnet.

#### 6. Ta et skjermbilde

Før du sender inn forespørselen din, ta et skjermbilde av appintegrasjonens **Generelt** fane som tydelig viser sign-in redirect URI-en du konfigurerte. Du legger dette ved aktiveringsforespørselen din.

***

### Innsending av aktiveringsforespørselen din

Når du har fullført konfigurasjonstrinnene for identitetsleverandøren din, kontakt CERRIX supportteam for å be om SSO-aktivering. Ta med følgende i forespørselen din:

**For Microsoft Entra ID:**

* Program-ID (klient-ID)
* Katalog-ID (leietaker-ID)
* Navn på egendefinert claim, hvis du konfigurerte et for brukermatching (ellers leser CERRIX `preferred_username`)
* Skjermbilde av Autentisering-siden som viser redirect URI-en din

**For Okta:**

* Client ID
* Metadata-URI-en til autorisasjonsserveren — for standardserveren er dette `https://[okta-domain]/oauth2/default/.well-known/openid-configuration`
* Navn på egendefinert claim, hvis du konfigurerte et for brukermatching (ellers leser CERRIX `preferred_username`)
* Skjermbilde av appintegrasjonen som viser sign-in redirect URI-en din

**For enhver leverandør:**

* Hvis organisasjonen din bruker et egendefinert domene eller en ikke-standard OIDC-metadata-URL, ta med hele metadata-URL-en (for eksempel `https://login.acme.com/.well-known/openid-configuration`).
* Gi oss beskjed om du vil beholde det standard CERRIX-innloggingsskjemaet tilgjengelig sammen med SSO, eller om du foretrekker kun SSO-innlogging.
* Gi oss beskjed hvis du vil ha stille innlogging aktivert (automatisk SSO-omdirigering ved sidelasting).

CERRIX-teamet vil gjennomgå forespørselen din, bruke konfigurasjonen og bekrefte når SSO er aktivert på miljøet ditt.

***

### Forskjeller mellom PKCE og implicit grant (legacy)

Hvis organisasjonen din allerede har SSO satt opp med CERRIX, bruker konfigurasjonen din mest sannsynlig **implicit grant** flyten — en eldre autentiseringsmetode som siden er blitt erstattet av PKCE.

|                     | PKCE (nåværende)                                                                    | Implicit grant (legacy)                                                |
| ------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **Security**        | Tokener utveksles server til server; nettleseren håndterer aldri rå tokener direkte | Tokener returneres i nettleserens URL, noe som gjør dem mer eksponerte |
| **Plattformtype**   | Enkeltsideapplikasjon (SPA)                                                         | Nett                                                                   |
| **Entra ID-støtte** | Fullt støttet og anbefalt av Microsoft                                              | Utfaset av Microsoft                                                   |
| **Okta-støtte**     | Standard for SPA-apper                                                              | Frarådet                                                               |
| **CERRIX-støtte**   | Anbefalt for alle nye og eksisterende oppsett                                       | Støttes kun for eksisterende oppsett                                   |

{% hint style="info" %}
Hvis du i dag bruker implicit grant-flyten og ønsker å bytte til PKCE, ta kontakt med CERRIXs supportteam. Migreringen krever en liten konfigurasjonsendring i identitetsleverandøren din og på vår side, og medfører ingen nedetid for brukerne dine.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/admin-settings/authentication-and-user-provisioning/sso-setup-guide.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.