Skip to main content

Ansattporten

For å registrere en klient i Ansattporten har du to muligheter:

Ansattporten er en relativt ny fellesløsning utviklet av Digdir for innlogging for ansatte i offentlige og tilknyttede virksomheter. Der ID‑porten er for innbyggere, brukes Ansattporten når sluttbrukeren er en ansatt som skal få tilgang til en tjeneste på vegne av sin arbeidsgiver, såkalt representasjon. Representasjon for virksomheter styres i Altinn, og Ansattporten knytter sammen deg som person med representasjon tildelt til ulike virksomheter i Altinn. Du kan lese mer om Ansattporten på Digdir sine sider.

🧪 Testmiljø for Ansattporten​

Digdir tilbyr Ansattporten i et testmiljø, der du kan teste applikasjonen din med syntetiske brukere fra Test-Folkeregisteret og syntetiske organisasjoner. For å registrere en klient mot Ansattporten sitt testmiljø så kan du benytte deg av Digdir sin selvbetjeningsløsning i test Du kan også teste ut å gi ulike representasjoner til syntetiske organisasjoner for test-brukere i Altinn sitt test-miljø.

🔄 Refresh-tokens​

Om Ansattporten 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 AnsattportenClient 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.

🔹 Autentiseringsmetoder og representasjon i Ansattporten​

Ansattporten støtter flere autentiseringsmetoder, avhengig av hvem sluttbrukeren er og hvilken autoritativ kilde tjenesten din trenger for representasjon:

  • BankID, Buypass, Commfides eller MinID: Brukeren autentiserer seg med fødselsnummer (pid), og kan representere en virksomhet basert på roller, tilgangspakker eller enkeltrettigheter i Altinn.
  • Microsoft Entra ID: Brukeren autentiserer seg med jobbkontoen sin, uavhengig av hvilken Entra-tenant arbeidsgiveren bruker. Dette gir deg kun autentisering, ikke representasjon, med mindre arbeidsgiveren i tillegg har konfigurert Virksomhetsbroen (pilot) for tjenesten din.

Tjenesten din velger selv hvilken eller hvilke metoder den vil tilby, se Valg av identitetstilbyder for en fullstendig sammenligning av alternativene, inkludert Ansattporten med Altinn-roller, Entra ID og Virksomhetsbroen og kun Entra ID.

Skisse over Ansattporten og ID-Porten.

🪪 Klientregistrering med AnsattportenClient​

En AnsattportenClient er en CRD som lar brukere deklarativt opprette og vedlikeholde Ansattporten-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 Ansattporten 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 AnsattportenClient

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

frontchannelLogoutURI (string, required) – URL som Ansattporten 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.

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

accessTokenLifetime (integer, optional) – Maksimal levetid i sekunder for access_token som returneres fra Ansattporten. 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.

Eksempel​

Følgende eksempel registrerer en klientintegrasjon mot Ansattporten. Når registrering er fullført vil Digdirator opprette Kubernetes-hemmeligheten ansattporten-secret i namespacet tilgangsstyring-main.

Klientregistrering mot Ansattporten med Digdirator
apiVersion: nais.io/v1
kind: AnsattportenClient
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
  postLogoutRedirectURIs:
    - https://test-app.atgcp1-sandbox.kartverket-intern.cloud/
  redirectURIs:
    - https://test-app.atgcp1-sandbox.kartverket-intern.cloud/oauth2/callback
  secretName: ansattporten-secret
Hemmelighet opprettet av Digdirator etter fullført klientregistrering
apiVersion: v1
kind: Secret
metadata:
  name: ansattporten-secret
  namespace: tilgangsstyring-main
data:
  ANSATTPORTEN_CLIENT_ID: ++++++++
  ANSATTPORTEN_CLIENT_JWK: ++++++++
  ANSATTPORTEN_ISSUER: ++++++++
  ANSATTPORTEN_JWKS_URI: ++++++++
  ANSATTPORTEN_REDIRECT_URI: ++++++++
  ANSATTPORTEN_TOKEN_ENDPOINT: ++++++++
  ANSATTPORTEN_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"
  ...