📝 Klientregistrering

Klientregistrering er en sentral del av tilgangsstyring med OAuth 2.0 og OIDC. Når du registrerer en klient, får applikasjonen sin egen identitet og kan autentisere seg mot de valgte identitetstilbyderne.

Vi anbefaler å ha et bevisst forhold til hvilke tjenester som skal dele samme audience. Det er ofte mer hensiktsmessig å velge en restriktiv tilnærming, der hver tjeneste får sin egen klientregistrering, fremfor å gruppere flere tjenester under én felles klient. Dette gir bedre kontroll over tilgangsstyring og sikkerhet.

Felles for alle identitetstilbydere på SKIP er at klientregistrering støttes fra plattformen ved hjelp av Kubernetes-operatorer.

• Digdirator håndterer klientregistrering mot Digdir sine fellesløsninger, nemlig ID-porten og Maskinporten.
• Azurerator tar seg av klientregistrering mot Microsoft Entra ID (tidligere kjent som Azure Active Directory).

Skiperator

CRD-en Application definert i Skiperator tilbyr et forenklet API for å registrere klienter mot ID-porten og Maskinporten. Vi jobber også med å innføre tilsvarende funksjonalitet for Entra ID, men det er ikke helt klart ennå.

Entra ID

🚧 Under utvikling 🚧

Automatisert klientregistrering mot Entra ID i SKiperator application-manifestet er for tiden under utvikling og er ikke helt klart ennå. Vi jobber hardt for å gjøre det tilgjengelig, og vi gleder oss til å vise deg hvordan du kan ta den i bruk så snart vi er klare! Følg med for oppdateringer.

ID-porten

Skiperator tilbyr støtte for å sette opp en klientintegrasjon mot ID-porten via spesifikasjonen til Application. Følgende eksempel konfigurerer en integrasjon av typen api_klient, setter redirect path til /oauth/callback og spesifiserer scopes openid og profile. Resten av feltene som støttes kan du finne i Skiperator sin API-dokumentasjon.

apiVersion: skiperator.kartverket.no/v1alpha1
kind: Application
metadata:
  name: application
  namespace: tilgangsstyring-main
spec:
  image: image
  port: 8080
  idporten:
    enabled: true
    integrationType: "api_klient"
    redirectPath: "/oauth/callback"
    scopes:
      - "openid"
      - "profile"

Fordelen med denne metoden er at Skiperator automatisk injiserer hemmelighetene som Digdirator oppretter som miljøvariabler i deploymenten til application. Dette gjør at applikasjonen enkelt kan få tilgang til hemmelighetene under kjøring.

Maskinporten

Skiperator tilbyr støtte for å sette opp en klientintegrasjon mot Maskinporten via spesifikasjonen til Application. Følgende eksempel demonstrerer en minimal konfigurasjon for å registrere en klient i Maskinporten. Resten av feltene som støttes kan du finne i Skiperator sin API-dokumentasjon.

apiVersion: skiperator.kartverket.no/v1alpha1
kind: Application
metadata:
  name: application
  namespace: tilgangsstyring-main
spec:
  image: image
  port: 8080
  maskinporten:
    enabled: true

Fordelen med denne metoden er at Skiperator automatisk injiserer hemmelighetene som Digdirator oppretter som miljøvariabler i deploymenten til application. Dette gjør at applikasjonen enkelt kan få tilgang til hemmelighetene under kjøring.

Digdirator / Azurerator

Man kan benytte seg direkte av CRD-ene (Custom Resource Definitions) som Digdirator og Azurerator introduserer for å registrere klienter mot ID-porten, Maskinporten og Entra ID. Fordelen med denne tilnærmingen er at man får full kontroll over konfigurasjonen og stor fleksibilitet ved å frikoble registreringen fra applikasjonen. Ulempen er at det krever mer innsikt i oppsettet, og at injisering av hemmeligheter i deploymenten må håndteres separat.

Digdirator introduserer CRD-ene IdportenClient og MaskinportenClient, som definerer konfigurasjonen for registrering av klienter mot henholdsvis ID-porten og Maskinporten. Azurerator introduserer CRD-en AzureAdApplication, som brukes til å registrere klienter mot Microsoft Entra ID.

Alle tre CRD-ene fungerer på samme måte: De overvåkes av sine respektive Kubernetes-operatører, som benytter konfigurasjonen til å registrere en klient mot den aktuelle identitetstilbyderen. Etter registreringen opprettes en Kubernetes-hemmelighet som inneholder nødvendige hemmeligheter og relevante URI-er. Disse brukes både til token-validering og for å gjennomføre ulike OAuth 2.0-flows.

AzureAdApplication

App-registreringer opprettet med Azureator følger følgende navnekonvensjon basert på AzureAdApplication-manifestet: cluster:namespace:name.

Spesifikasjonen til AzureAdApplication

spec (required) – Spesifikasjon for `AzureAdApplication

allowAllUsers (bool, required) – Bestemmer om alle brukere i tenanten som Azurerator er konfigurert mot skal få tilgang.

claims (object, optional) – Definerer konfigurasjon av claims som inkluderes i tokenene som returneres til Entra ID applikasjonen.

groups ([]object, optional) – En liste over Entra ID gruppe ID-er som skal inkluderes i `groups-claimet i tokenene utstedt av Entra ID. Dette tildeler også grupper til app-registreringen brukt for tilgangskontroll. Kun direkte medlemmer av gruppene får tilgang.

id (string, required) – Objekt-ID-en (OID) til en Entra ID-gruppe.

replyUrls ([]object, required) – URL-er som applikasjonen godtar som svaradresser etter autentisering.

url (string, required) – En godkjent svaradresse (reply URL) for applikasjonen.

logoutUrl (string, optional) – URL-en brukere blir omdirigert til når de logger ut av applikasjonen..

preAuthorizedApplications ([]object, optional) – Definerer andre app-registreringer som er forhåndsautorisert til å få tilgang til denne applikasjonen. Her refereres det til tilsvarende AzureAdApplication.

application (string, required) – Navnet på den forhåndsgodkjente applikasjonen.

namespace (string, required) – Namespacet hvor den forhåndsgodkjente applikasjonen befinner seg.

cluster (string, required) – Clusteret hvor den forhåndsgodkjente applikasjonen befinner seg.

permissions (object, optional) – Spesifiserer hvilke claims den forhåndsautoriserte applikasjonen har.

scopes ([]string, optional) – Liste med egendefinerte tilgangs-scopes tildelt til den forhåndsautoriserte appliaksjonen.

roles ([]string, optional) – Liste med egendefinerte tilgangs-roller tildelt til den forhåndsautoriserte appliaksjonen.

secretName (string, required) – Navnet på Kubernetes-hemmeligheten der hemmeligheter og annen informasjon for Entra ID applikasjonen lagres.

secretKeyPrefix (string, optional) – Et valgfritt brukerdefinert prefiks som brukes på nøklene i den genererte hemmeligheten, og erstatter standardprefikset (AZURE).

secretProtected (bool, optional) – Angir om hemmeligheten skal tilbaketrekkes selv når den ikke er i bruk.

singlePageApplication (bool, optional) – Angir om denne Entra ID-applikasjonen skal registreres som en single-page-application for bruk i klient-side-applikasjoner uten tilgang til hemmeligheter.

Eksempel

Følgende eksempel er et YAML-manifest som oppretter app-registreringen atgcp1-sandbox:tilgangsstyring-main:test-app. Den gir kun tilgang til direkte medlemmer av gruppene med objekt-ID 2720e397-081d-4d9b-852e-0d81f45a304f eller c3c94454-aefc-44f9-9076-58ea47547941. Den forhåndsautoriserer også Entra ID klienten atgcp1-dev:other-namespace:other-app. Når registrering er fullført vil Azurerator automatisk opprette Kubernetes-hemmeligheten entraid-secret i namespacet tilgangsstyring-main.

apiVersion: nais.io/v1
kind: AzureAdApplication
metadata:
  name: test-app
  namespace: tilgangsstyring-main
spec:
  allowAllUsers: false
  claims:
    groups:
      - id: 2720e397-081d-4d9b-852e-0d81f45a304f
      - id: c3c94454-aefc-44f9-9076-58ea47547941
  replyUrls:
    - url: https://test-app.atgcp1-sandbox.kartverket-intern.cloud/oauth2/callback
  preAuthorizedApplications:
    - application: other-app
      namespace: other-namespace
      cluster: atgcp1-dev

IdportenClient

🚧 Under arbeid 🚧

Dette innholdet er under arbeid og forhåpentligvis straks klart!

MaskinportenClient

🚧 Under arbeid 🚧

Dette innholdet er under arbeid og forhåpentligvis straks klart!