Vurdere å innføre granulert styring av SSO i ID-Porten

[steinarnoem-digdir]

Overordnet beskrivelse

Bakgrunn

ID-Porten tilbyr i dag SSO som en binær funksjon på klient-/RP-nivå.
Klienten er enten med i SSO-økosystemet, eller så er den det ikke.
Denne modellen har tjent oss godt gjennom mange år, men byr på flere utfordringer i dagens tjenestelandskap, hvor antallet integrasjoner, variasjonen i tillitsnivåkrav og trusselbildet har endret seg betydelig.

Hva skal vurderes?

Skal/kan vi erstatte dagens binære SSO-modell med en fleksibel modell der grupper av RP kan defineres som SSO-domener («øyer»), slik at sesjonsdeling skjer kontrollert basert på risiko, sektor eller brukerbehov.

Kriterier

• Forvaltningen kan konfigurere SSO-domener tilpasset risiko og brukerflyt.
• Brukere får økt forutsigbarhet og kontroll over hvilke tjenester som deler sesjon.
• Dagens binære modell kan fortsatt tilbys som ett av flere konfigurasjonsvalg i en overgangsperiode.
• Endringen er bakoverkompatibel for RPer som ikke aktivt tar i bruk ny funksjonalitet.

Forventet resultat

Åpne spørsmål

• Skal SSO domener defineres av Digdir, av virksomhetene selv, eller av en kombinasjon?
• Hvordan håndtere RP-er som hører til flere domener?
• Hvilken default skal gjelde for nye klienter? Opt-in til økosystem SSO? Isolert SSO?
• Hvordan koordinere med fremtidig EUDI-W modell der sesjonsbegrepet blir annerledes?

Hvordan skal det fungere?

Løsningsmønster som skal utredes

Det finnes flere mulige designvalg, og arbeidet består i å vurdere kombinasjoner av disse:

Gruppering av klienter

• Skal nye grupper opprettes og konfigureres på tvers av alle kunder i Kundeportal/Selvbetjening (klienter knyttes til navngitte SSO-domener)?
• Skal grupper eies av RP/Klient? Ny gruppe opprettes i kontekst av RP/Klient?

Sesjonshåndtering og semantikk

• Skal separate sesjoner per SSO-domene ha egne levetider?
• Skal vi støtte en step-up modell der step-up til høyere tillitsnivå alltid krever ny brukerinteraksjon, uavhengig av sesjonsstatus?

Bruk av internasjonale standarder:

• Skal vi basere løsningen på eksisterende OIDC-mekanismer, eller styre og håndheve alt sentralt i ID-Porten?
• Ønsker vi en hybrid modell, hvor både RP bruker protokollmekanismer og ID-Porten håndterer SSO-øylogikk?
• Påvirke standardardene ved å utarbeide forslag til OIDF rundt sesjonshåndtering og autentiseringskontekst?
• Eventuelle behov for nye claims eller request-parametre som bør tas opp i OIDF eller IETF?

Brukerperspektiv:

• Sesjonsoversikt der bruker ser aktive SSO sesjoner?
• Mulighet for selektiv utlogging per domene?
• Eksplisitt brukerbekreftelse ved overgang mellom SSO øyer?

Håndheving av tillitsnivå:

• Sentral håndheving i ID-Porten av krav om reautentisering ved step-up i tillitsnivå, uavhengig av implementasjon i RP (defense in depth)?
• Strengere krav og eventuell validering av RP-implementasjoner som ikke håndterer ac korrekt?

Avhengigheter og hensyn som må tas

• Ansattporten og Maskinporten — hvilke prinsipper skal være konsistente på tvers?
• eIDAS 2.0 og kommende krav til wallet-basert autentisering?
• Selvbetjeningsløsningen: Brukeropplevelse for konfigurasjon av SSO domener?
• Eksisterende RP: migrasjonsstrategi og kommunikasjon.

Gjennomføring

Avhengigheter

• Draft avhengighet

Oppgaver

• Draft epos