idporten-utland

Løsningen baserer seg på gjenbruk av eID-løsninger som brukeren allerede har, som Google/Apple-ID. På denne måten slipper brukeren å måtte lage nok en brukerkonto med passord som lett kan glemmes. Alle som har en smart-telefon har en slik eID.

For at løsningen skal kunne brukes i ulike sektorer og kunne støtte den variasjon av fagsystem og identifikatorer som er i bruk i offentlig sektor, kan kunder be om at apple/google-innloggingen blir beriket med norske sektor-spesifikke identifikatorer som feks Nasjonal Felles Hjelpenummer fra helsesektoren. Første gang en eID logger på vil idporten-utland rekvirere en ny sektor-identifikator fra forespurt register og lagre en permanent kobling mellom eID og identifikator i idporten-utland sin lokale brukerdatabase. Ved senere innlogginger med samme eID, mottar derfor kunde samme sektor-identifikator.

idporten-utland bruker merkenavnet Connect2Norway ut mot sluttbruker.

Aktører som inngår:

Figuren under viser hvilke aktører som inngår ved lansering. Senere kan det bli koblet på andre registre med egne sektor-identifikatorer.

Flytskjema:

Sekvensdiagrammet viser hva som skjer når en tjeneste trenger en innlogging med FH-nummer:

Metadata, endepunkt og klientregistreringer

idporten-utland kjører i et eget, Kubernetes-basert on-prem driftsmiljø hos driftsleverandør TietoEvry.

Løsningen er koblet mot Selvbetjening på samarbeidsportalen, slik at det er lett å integrere mot den. Det er ennå ikke lagt til eget valg for idporten-utland som integration_type i Samarbeidsportalen, slik at alle integrasjoner som virker i den “vanlige” ID-porten (OIDC) også virker mot id-porten utland. Vi anbefaler dog at kunder oppretter egne integrasjoner spesifikt for idporten-utland. For testmiljø er det VER2 som skal benyttes. Husk å opprette integrasjonen som type API_KLIENT, slik at du kan få registrert scopes på den.

Merk: Det kan ta opptil 10 minutter fra en registrerer en klient i selvbetjeningsløsningen, til den er aktiv i idporten-utland.

Merk: Pga. en intern begrensning er det kun klienter registert via Selvbetjening med 1 og bare 1 redirect-uri som virker i idporten-utland p.t.

Merk: Provideren støtter ikke alle protokoll-varianter som er annonsert på .well-known-endepunktet

Testbrukere

Man må opprette egne google/apple-brukere for å teste idporten-utland.

Eventelt kan man bruke “TestID”, og fylle ut et norsk syntaktisk gyldig fødselsnummer, så lenge man bruker nummer som ikke er tildelt ekte personer (altså finnes i produksjon i Folkeregisteret). Vi anbefaler å bruke syntetiske fødselsnummer, dvs. nummer som har 80 som verdi for måned.

Test-tjeneste

Den enkleste måten å teste tjenesten på, er å logge inn til profil-sida med en testbruker: https://idporten-utland-test.digdir.eon.no/idporten-utland-registration/

Alternativ kan man bruke en teknisk test-klient dersom man vil utforske selve protokollen mer: https://idporten-utland-test.digdir.eon.no/idporten-test-client/

Grensesnittsdefinisjon

• Bruker OIDC med oauth2.1 i botn, dvs authorization-code-flow med PKCE+state+nonce er påkrevd for alle klienter.

• Klienter bruker primært scopes for å få de sektor-spesifikke identifikatorene de ønsker

  • t.d idporten:utland:fhnummer dersom klienten ønsker Nasjonalt Felles Hjelpenummer

  • dersom forespurt informasjon ikkje finst tilknytta brukar-kontoen’en frå før, so vert det rekvirert frå autorativ kjelde der&då.

  • openid profile er ein gyldig kombinasjon, dvs. lov å logge inn utan noko beriking eller kobling

• Klienter må håndere et bredt mulighetsrom av “sikkerhetsnivå”, dvs. en innlogget bruker kan ha:

  • svak eller sterk identitetskontroll

  • svake eller sterke autentiseringsmekanismer

  • svake eller sterke koblinger til nasjonale/sektorvise norske identifikatorer

• OP-initiert logout (både front-channel og back-channel) er p.t. ikkje støtta

*

Autentiseringsforespørsel (/authorize)

Følgende scopes støttes utover openid profile:

Følgende claims er viktige å få korrekt i requesten:

Autentiseringsrespons (id_token)

Claims i id_token

I tillegg er det selvsagt standard OIDC / oauth2 claims i tokenet, som valideres ihht reglene i spesifikasjonen.

Eksempel på id-token

I dette tilfellet har klienten forespurt scope openid idporten:utland:fhnummer

    {
      "sub" : "en pseodonym identifikator",
      "iss" : "https://idporten-utland-test.digdir.eon.no/c2id",
      "aud" : "b7198ea6-14f0-488f-bb9a-206993ad28bc",
      "iat" : 1616765456,
      "exp" : 1616765576,
      "auth_time" : 1616765455,
      "nonce" : "qDHodUys-yzbA961atMXwfk3gBefUn27i7m4m-bEc_4",
      "sid" : "n3ss5nXYYkLRm8J_KZqP-pjsPli5AuKGDiAwRAn5nxE"
      "locale" : "nb",

      "acr" : "low",
      "amr" : [ "Apple" ],  
      "fhnummer": "80012054321",
      "mobile": "+4799998888"
      "email": "email@example.com"

    }