Skip to main content

Innlogging og utlogging

Det går an å konfigurere Ztoperator til å håndtere innlogging og utlogging av sluttbrukere på vegne av applikasjonen din. Dette gjøres ved å sette opp spec.autoLogin og spec.oAuthCredentials i Ztoperator-AuthPolicy-ressursen din. spec.autoLogin konfigurerer ulike endepunkter brukt i innloggings -og utloggingsflyten, mens spec.oAuthCredentials peker til en Kubernetes-hemmelighet som inneholder klient-ID client_id og klienthemmelighet client_secret for en registrert OIDC-klient hos identitetstilbyderen.

Nødvendig konfigurasjon i AuthPolicy​

Følgende eksempel viser feltene som skrur på innlogging i en AuthPolicy:

AuthPolicy med innlogging
apiVersion: ztoperator.kartverket.no/v1alpha1
kind: AuthPolicy
metadata:
  name: my-auth-policy
spec:
  autoLogin:
    enabled: true
    scopes:
      - openid
      - profile
    redirectPath: /oauth2/callback
    logoutPath: /logout
  oAuthCredentials:
    secretRef: my-oauth-secret
    clientIDKey: CLIENT_ID
    clientSecretKey: CLIENT_SECRET
  # Må defineres dersom identitetstilbyderen utsteder tokens med et `aud`-claim
  # som f.eks. ID-Porten, Ansattporten, Entra ID og TokenX
  allowedAudiences:
    - valueFrom:
        secretKeyRef:
          name: my-oauth-secret
          key: CLIENT_ID
  # Påkrevd dersom identitetstilbyderen krever resource indicators
  # som f.eks. ID-porten og Ansattporten
  acceptedResources:
    - <URI, f.eks. https://myapp.atgcp1-dev.kartverket-intern.cloud>
  ... # øvrige påkrevde/valgfrie felter
Les mer om sammenheng mellom Ztoperator-felter og din klientregistreringen

Ztoperator registrerer ikke klienten for deg, så konfigurasjonen i AuthPolicy må stemme overens med klienten du har registrert hos identitetstilbyderen. Tabellen under viser hvordan feltene henger sammen:

Felt i AuthPolicyKrav til klientregistreringen
oAuthCredentialsHemmeligheten må inneholde klient-ID og klienthemmelighet for klienten. Klienten må autentisere seg mot token-endepunktet med klienthemmelighet i request body (client_secret_post). private_key_jwt støttes ikke.
autoLogin.redirectPathhttps://<host><redirectPath> må være registrert som redirect URI. Host hentes fra forespørselen, så det må registreres én redirect URI per ingress applikasjonen nås på.
autoLogin.scopesKlienten må ha tilgang til scopene som etterspørres.
autoLogin.postLogoutRedirectUriURI-en må være registrert som gyldig redirect URI etter utlogging (post_logout_redirect_uri).
autoLogin.logoutPathIngen krav. Ztoperator sender brukeren til identitetstilbyderens end_session_endpoint fra discovery-dokumentet.
allowedAudiencesMå inneholde verdien identitetstilbyderen setter i aud-claimet, som normalt er klient-ID-en.
acceptedResourcesPåkrevd for ID-porten og Ansattporten. Verdiene sendes som resource i autorisasjonsforespørselen, og settes i aud-claimet i tokenet.

Klienten må i tillegg tillate grant-typen authorization_code. For å holde brukeren innlogget med refresh-tokens må klienten også tillate refresh_token, se lengre brukersesjoner.

Se API-dokumentasjonen for en fullstendig beskrivelse av feltene.

Nødvendig konfigurasjon i Skiperator-applikasjonen​

OBS

For at innlogging skal fungere med Ztoperator, må den beskyttede Skiperator-applikasjonen oppdateres med spec.podSettings.annotations.sidecar.istio.io/userVolume og spec.podSettings.annotations.sidecar.istio.io/userVolumeMount.

Ztoperator ikke har lov til å laste inn hemmeligheter som brukes for innlogging i den beskyttede applikasjonen. For å løse dette er man nødt til å legge til en konfigurasjon på den beskyttede Skiperator-applikasjonen for at innloggingshemligheter som Ztoperator håndterer skal kunne lastes inn. Følgende eksempel viser hvordan dette kan gjøres i en Skiperator-applikasjon. Det er viktig at <NAVN PÅ AUTHPOLICY> erstattes med navnet på din Ztoperator-AuthPolicy. Hvis din AuthPolicy for eksempel heter my-auth-policy, så må du sette secretName: my-auth-policy-envoy-secret.

Skiperator-applikasjon med Ztoperator-innlogging
apiVersion: skiperator.kartverket.no/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  podSettings:
    annotations:
      sidecar.istio.io/userVolume: |
        [
          {
            "name": "istio-oauth2",
            "secret": {
              "secretName": "<NAVN PÅ AUTHPOLICY>-envoy-secret"
            }
          }
        ]
      sidecar.istio.io/userVolumeMount: |
        [
          {
            "name": "istio-oauth2",
            "mountPath": "/etc/istio/config",
            "readonly": true
          }
        ]
  image: ghcr.io/kartverket/myapp:latest
  port: 8080
  ingresses:
    - myapp.atgcp1-dev.kartverket-intern.cloud
  redirectToHTTPS: true
  accessPolicy:
    inbound:
      rules:
        - application: myjob-skipjob

Lengre brukersesjoner med offline_access og refresh-tokens​

Som standard vil en brukersesjon utløpe når access-tokenet fra identitetstilbyderen utløper. For applikasjoner som krever lengre sesjoner uten at brukeren skal måtte logge inn på nytt, kan scopet offline_access legges til i spec.autoLogin.scopes. Dette ber identitetstilbyderen om å utstede et refresh-token i tillegg til access-tokenet.

Ztoperator vil automatisk bruke refresh-tokenet til å hente nye access-tokens i bakgrunnen når det eksisterende utløper, slik at brukeren holdes innlogget uten avbrudd.

Sikkerhetshensyn

Refresh-tokens gir langvarig tilgang, som kan ha konsekvenser og muliggjøre misbruk. Sørg for at du kun bruker offline_access når det er et reelt behov for lengre sesjoner.

ID-porten og Ansattporten

For ID-porten og Ansattporten styres utstedelse av refresh-tokens ikke av scopet offline_access, men av klientregistreringen hos Digdir. Du trenger derfor ikke legge til offline_access i spec.autoLogin.scopes for disse tilbyderne. Se ID-porten og Ansattporten under Klientregistrering.

Du kan ta i bruk offline_access i din AuthPolicy ved å legge det til i spec.autoLogin.scopes-listen:

AuthPolicy med offline_access for lengre sesjoner
apiVersion: ztoperator.kartverket.no/v1alpha1
kind: AuthPolicy
metadata:
  name: min-authpolicy
spec:
  autoLogin:
    enabled: true
    logoutPath: /logout
    redirectPath: /oauth2/callback
    scopes:
      - offline_access
      ...
  ...

Når offline_access er inkludert i scopes, vil flyten se slik ut:

  1. Brukeren logger inn og identitetstilbyderen returnerer både et access-token og et refresh-token.
  2. Ztoperator lagrer refresh-tokenet kryptert i session-cookien på klientsiden.
  3. Når access-tokenet er utløpt eller ikke lenger tilgjengelig, bruker Ztoperator automatisk refresh-tokenet til å hente et nytt access-token via token refresh-flyten (RFC 6749) – uten at brukeren merker noe.
  4. Sesjonen varer inntil refresh-tokenet selv utløper eller trekkes tilbake av identitetstilbyderen.