OIOSAML

Det kan man godt, men det er ikke en løsning, vi anbefaler. 

Der er ingen validering af NSIS sikringsniveauer indbygget i det gamle framework, så man skal selv håndtere den del, hvis man ikke opdaterer til OIOSAML.java 2.2.0 eller nyere.

Herudover er der ingen understøttelse for de nye attributter, der udstedes af det nye NemLog-in, så dem skal man ligeledes selv håndtere. Det er ikke muligt at efterspørge en specifik profil og/eller andre af de funktioner, som det nye NemLog-in understøtter.

Ja, man kan roligt opdatere allerede nu, da OIOSAML.java 2.2.0 og nyere også fungerer fint med det nuværende NemLog-in.

Ikke endnu, men vi er opmærksomme på spørgsmålet. 

Hvis brugerens NemID er på NSIS Betydelig, sendes dette tilbage i Assertion.

Hvis brugerens NemID ikke er på NSIS Betydelig, sendes den gamle LoA attribut fra OIOSAML 2.0.9.

Ved go-live af det nye NemLog-in, er det kun model to, der er understøttet. Constraints (dataafgrænsninger) er i pipeline, men der er ingen officiel dato endnu.

Hvis tjenesteudbyderes løsninger i dag anvender de attributter, der udfases, skal disse tjenester opdateres. Det skal de være senest ved go-live for NemLog-in broker . Digitaliseringsstyrelsen har udviklet en tringuide, til at teste, hvordan tjenesteudbyderens it-systemer reagerer, når attributterne ikke længere leveres af NemLog-in.

Læs mere og find tringuide

Det er ikke nødvendigt at skelne imellem hvilket identifikationsmiddel der er anvendt. Både migrerede og ikke-migrerede brugere tildeles samme type identifikatorer (fx tjenesteudbydersspecifikt UUID) iht. OIOSAML3, og der er netop tale om at tjenesteudbyder-specifikke identifikatorer bevares ifm. migrering. Derimod er det vigtigt at I som tjenesteudbyder tager stilling til hvilket sikringsniveau, NemLog-in meddeler i assertion.

I OIOSAML 3 specifikationen kan man se hvilke attributter, der er tilgængelige. Fullname, OrganisationName, CVR, RID er alle eksempler på attributter, som kan modtages i assertion.

Læs mere om OIOSAML 3

OIOSAML 2.1.0 er aktivt nu, på beta-testmiljøet. Der er desuden udgivet vejledning til at afprøve sin integration uden de OCES-attributter, som udfases med 2.1.0.

Hent vejledningen.

OIOSAML 2.1.0 vil desuden komme i integrationstestmiljøet forud for idriftsættelsen i produktion.

Vi anbefaler generelt, at den seneste version af referenceimplementeringer ibrugtages hurtigst muligt. Både i forhold til kompatibilitet og sikkerhed.

Hvis man er ny tjenesteudbyder på NemLog-in, skal man tilslutte sig OIOSAML 3.

Vi har noteret ønsket i backlog.

Nej, hvis I anvender AssertionValidatorService og AuthenticatedFilter fra OIOSAML3.Java, foretages den nødvendige kontrol af NSIS LoA/Assurance Level jf. den konfiguration, I har angivet.

Begge IdP'er (2.1.0 og 3.0.2) kan autentificere brugere med både NemID og MitID i migreringsperioden. 

Ja.

Migreringen forventes at være afsluttet, når MitID Erhverv bliver lanceret i oktober 2022. Der kan dispenseres ved fx tjenester, der udgår inden for kort tid eller erstattes af ny tjeneste.

Der er ikke truffet beslutning om endelig nedlukning.

Det styres i administrationsportalen, hvor tilslutning til OIOSAML 2.1.0 og 3.0.2 er to forskellige indgange.

Tjenester, der i dag er tilsluttet 2.0.9, skal ikke gøre noget for at komme på 2.1.0 (endpoint opgraderes automatisk), så det er kun ved tilslutning til 3.0.2, at man aktivt skal gøre noget som tjenesteudbyder.

Alle tjenesteudbydere, der ønsker at integrere til NemLog-in, skal anvende OIOSAML 3 profilen. 

Der står krav til metadata i OIOSAML 3.0.2 profilen, og på vejledningssiderne kan I finde et eksempel.

I det nævnte tilfælde er der ingen funktionelle forskelle. Vi anbefaler dog altid, bl.a. af sikkerhedsmæssige grunde, at man opgraderer til de nyeste versioner.

Ja. I dag vedligeholdes og ligger OIOSAML.NET på GitHub. Diskussionsforum på Digitalisér.dk findes fortsat.

Denne feature vil blive tilføjet.

Nej, det er det ikke. 

Det vigtigste er, at jeres tjeneste fungerer uden de attributter, der udfases forud for NemLog-in brokerens go-live. Dog anbefaler vi altid, at man opgraderer til de nyeste versioner af referenceimplementeringer.