Skip to main content

ID-Porten

For å registrere en klient i ID-porten har du to muligheter:

🧪 Testmiljø for ID-Porten​

Digdir tilbyr ID-Porten i et testmiljø, der du kan teste applikasjonen din med syntetiske brukere fra Test-Folkeregisteret. For å registrere en klient mot ID-Porten sitt testmiljø så kan du enten gjøre det i Digdir sin selvbetjeningsløsning i test eller opprette en IDPortenClient-ressurs i dev-clustrene til SKIP, i.e. atgcp1-dev eller atkv3-dev.

🔄 Refresh-tokens​

Om ID-porten utsteder refresh-tokens bestemmes av klientregistreringen, ikke av scopes i hver forespørsel (f.eks. offline_access). Klienten får kun utstedt refresh-token dersom den er registrert med refresh_token som tillatt grant-type, i tillegg til authorization_code.

  • Selvbetjeningsløsningen: Du velger selv om klienten skal ha grant-typen refresh_token, og kan sette levetid for refresh-token og authorization, samt om refresh-tokenet skal være engangs eller gjenbrukbart.
  • Digdirator: En IDPortenClient registreres alltid med grant-typen refresh_token. Refresh-tokenet er engangs, og både levetiden for refresh-token og authorization settes til spec.sessionLifetime. Dette kan ikke skrus av.

Levetiden på refresh-tokenet bestemmer hvor lenge sesjonen kan være inaktiv, mens levetiden på authorization bestemmer maksimal levetid for sesjonen. Se Digdir sin dokumentasjon om registrering av klienter for detaljer.

🪪 Klientregistrering med IDPortenClient​

En IDPortenClient er en CRD som lar brukere deklarativt opprette og vedlikeholde ID-Porten-klientregistreringer. Etter å ha fullført opprettelsen, vil Digdirator opprette en Kubernetes-hemmelighet (Secret) i samme namespace med hemmeligheter som kan brukes av applikasjoner til tilgangsstyring, som for eksempel client_id, private_key_jwt, diverse URL-er og lignende.

caution

Ztoperator støtter per nå kun klientregistreringer som identifiserer seg mot ID-porten med client_secret_post. Ettersom Digdirator kun oppretter klientregistreringer med private_key_jwt, så vil disse ikke fungere med Ztoperator. Vi jobber med å få på plass støtte for private_key_jwt i Ztoperator.

Spesifikasjon​

spec (object, required) – Spesifikasjon til IDPortenClient

secretName (string, required) – Navnet på den resulterende Secret-ressursen som vil bli opprettet.

frontchannelLogoutURI (string, required) – URL som ID-porten omdirigerer til når en utlogging utløses av en annen applikasjon.

redirectURIs ([]string, required) – Liste over redirect URI-er som skal registreres hos DigDir.

integrationType (string, optional) – Definerer integrasjonstypen for klienten. Bestemmer hvilke scopes som kan registreres. Kan ikke endres etter opprettelse. Tillatte verdier: krr, idporten, api_klient.

scopes ([]string, optional) – Definerer OAuth2-scopes for klienten. Begrenset basert på integrationType.

postLogoutRedirectURIs ([]string, optional) – Liste over gyldige URI-er hvor ID-porten kan omdirigere etter utlogging.

accessTokenLifetime (integer, optional) – Maksimal levetid i sekunder for access_token som returneres fra ID-porten. Min: 1, maks: 3600.

clientURI (string, optional) – URL til klienten brukt av DigDir når en 'tilbake'-knapp vises eller ved feil.

clientName (string, optional) – Navnet på klienten registrert hos DigDir. Vises under innlogging for brukerorienterte flyter.

sessionLifetime (integer, optional) – Maksimal øktlevetid i sekunder for en innlogget sluttbruker for denne klienten. Min: 3600, maks: 28800.

ssoDisabled (bool, optional) – Kontrollerer Single Sign-On-oppsettet for klienten. Hvis satt til true, er SSO deaktivert.

Eksempel​

Følgende eksempel registrerer en klientintegrasjon mot ID-porten med integrasjonstypen idporten. Når registrering er fullført vil Digdirator opprette Kubernetes-hemmeligheten idporten-secret i namespacet tilgangsstyring-main.

Klientregistrering mot ID-Porten med Digdirator
apiVersion: nais.io/v1
kind: IDPortenClient
metadata:
  name: test-client
  namespace: tilgansstyring-main
spec:
  clientName: Test Application
  clientURI: https://test-app.atgcp1-sandbox.kartverket-intern.cloud
  frontchannelLogoutURI: https://test-app.atgcp1-sandbox.kartverket-intern.cloud/oauth2/logout
  integrationType: idporten
  postLogoutRedirectURIs:
    - https://test-app.atgcp1-sandbox.kartverket-intern.cloud/
  redirectURIs:
    - https://test-app.atgcp1-sandbox.kartverket-intern.cloud/oauth2/callback
  scopes:
    - openid
    - profile
  secretName: idporten-secret
Hemmelighet opprettet av Digdirator etter fullført klientregistrering
apiVersion: v1
kind: Secret
metadata:
  name: idporten-secret
  namespace: tilgangsstyring-main
data:
  IDPORTEN_CLIENT_ID: ++++++++
  IDPORTEN_CLIENT_JWK: ++++++++
  IDPORTEN_ISSUER: ++++++++
  IDPORTEN_JWKS_URI: ++++++++
  IDPORTEN_REDIRECT_URI: ++++++++
  IDPORTEN_TOKEN_ENDPOINT: ++++++++
  IDPORTEN_WELL_KNOWN_URL: ++++++++
type: Opaque

🔁 Rullering av hemmeligheter​

Digdirator roterer ikke hemmeligheter automatisk. I stedet fornyes den samme hemmeligheten (og tilhørende JWKS) i det uendelige, slik at samme JWKS kan brukes så lenge klientregistreringen eksisterer. Ønsker du likevel å rullere hemmeligheten har du to muligheter:

Opprette en ny hemmelighet med ny JWKS​

Ved å endre secretName i spec vil Digdirator opprette en helt ny Secret-ressurs med et nytt JWKS. Den gamle hemmeligheten, og den tilhørende JWKS-en, vil fortsette å være tilgjengelig og gyldig så lenge den fremdeles refereres til av kjørende workloads. Dette gjør det mulig å rullere hemmeligheten uten nedetid, ved å:

  1. Opprette en ny hemmelighet med nytt JWKS ved å endre secretName i spec.
  2. Oppdatere alle workloads som bruker den gamle hemmeligheten til å bruke den nye.
  3. Digdirator vil automatisk rydde opp den gamle hemmeligheten når ingen workloads lenger refererer til den.

Rullere hemmeligheten in-place​

Du kan tvinge frem en umiddelbar rullering av hemmeligheten ved å legge følgende annotasjon på ressursen:

metadata:
  annotations:
    digdir.nais.io/rotate: "true"
  ...
spec:
  ...
caution

Merk at denne fremgangsmåten invaliderer den gamle JWKS-en umiddelbart, selv om en kjørende pod fortsatt bruker den. Dette kan medføre nedetid for applikasjonen din dersom ikke alle kjørende pods får hentet den nye hemmeligheten med det samme.

Sørge for at applikasjonen plukker opp den nye hemmeligheten​

Uavhengig av hvilken fremgangsmåte du velger, må applikasjonen din laste inn den oppdaterte hemmeligheten for at rulleringen skal ha noen effekt. Legg følgende annotasjon på din Skiperator-Application for at Reloader automatisk skal rulle ut nye pods når hemmeligheten endres:

apiVersion: skiperator.kartverket.no/v1alpha1
kind: Application
metadata:
  ...
spec:
  podSettings:
    annotations:
      reloader.stakater.com/search: "true"
  ...