- Supporten for OIOSAML2 ophører. Det betyder eksempelvis, at vi ikke længere hjælper med at give adgang til tekniske administratorer, samt at vi ikke hjælper med at hente metadata ud fra eksisterende OIOSAML2 systemer.
- Vi vedligeholder ikke længere protokollen. I praksis betyder det, at eventuelle fejl i OIOSAML2 snitfladen ikke rettes.
I kan stadig få hjælp til at migrere jeres tjenester fra OIOSAML2 til OIOSAML3.
Se infovideo om OIOSAML
Bemærk: OIOSAML 2.1.0 erstattede OIOSAML 2.0.9, da NemLog-in broker gik live 22. september 2021. Læs mere nedenfor i afsnittet "Vigtigt om OIOSAML 2".
Download præsentationen fra infovideoen om OIOSAML (PDF)
Overgang til OIOSAML 3
OIOSAML 2 bliver erstattet af OIOSAML 3 ved overgangen til NemLog-in broker. Overgangen til den nye OIOSAML profil betyder, at I skal tilpasse jeres tjeneste, så den kan bruge den nye profil. Alle tjenesteudbydere, der ønsker at integrere til NemLog-in, skal anvende OIOSAML 3 profilen.
Der er udviklet opdaterede referenceimplementeringer til OIOSAML.Java og OIOSAML.net i beta-version samt beta-dokumenation til OIOSAML 3, som er tilgængeligt nu. Det er også muligt at teste OIOSAML 3 snitfladen i det nye beta-testmiljø.
Gå til side for dokumentation, test og referenceimplementeringer
Parallel understøttelse i migreringsperioden
Den nye NemLog-in broker har to aktive SAML IdP’er, som kan håndtere brugerautentifikation:
- Den nuværende OIOSAML 2.0.9 IdP, som skifter til OIOSAML 2.1.0 snitfladen
- Den nye OIOSAML 3.0.3 IdP
Begge IdP’er vil være aktive i en længere overgangsperiode, og NemLog-in vil kunne håndtere både brugere med NemID og MitID på begge IdP’er. NemLog-in oversætter til den version af OIOSAML, som tjenesteudbyderen kan håndtere og fungerer dermed som en ”bro”. Der er endvidere single sign-on mellem de to IdP’er. Dette sikrer en smidig indfasning både for slutbrugere og tjenesteudbydere.
Vigtigt om OIOSAML 2
OCES-attributter, der udfases ved opdatering til OIOSAML 2.1.0
Forud for overgangen til OIOSAML 3 bliver OIOSAML 2.0.9 profilen erstattet af OIOSAML 2.1.0. Det skyldes, at en række attributter vedr. OCES certifikater udfases.
Tjenesteudbydere, som er koblet på nuværende OIOSAML 2.0.9 IdP i NemLog-in, skal derfor forberede sig på, at de med go-live for NemLog-in broker ikke længere kan få disse attributter fra NemLog-in. Ændringer i attributter gælder for brugere, som logger ind med MitID og NemID.
Herudover vil Security Token Service (STS) ikke levere de udfasede OCES attributter fra go-live af NemLog-in broker, når OIOSAML opdateres fra 2.0.9 til 2.1.0. Hvis man som tjenesteudbyder agerer i rollen som Web Service Provider, skal man derfor sikre sig, at der ikke længere er en afhængighed til de attributter, der udfases.
I kan teste, hvordan jeres it-system reagerer, når attributterne udfases, ved brug af Nemlog-ins integrationstestmiljø, hvor attributterne allerede er udfaset.
Følgende attributter bliver udfaset:
- UserCertificate (urn:oid:1.3.6.1.4.1.1466.115.121.1.8)
- Certificate issuer (urn:oid:2.5.29.29)
- (Certificate) serial number (urn:oid:2.5.4.5)
- IsYouthCert (dk:gov:saml:attribute:IsYouthCert)
- UniqueAccountKey (dk:gov:saml:attribute:UniqueAccountKey)
- Postal address (urn:oid:2.5.4.16)
- Title (urn:oid:2.5.4.12)
- Organization unit (urn:oid:2.5.4.11)
- UserAdministratorIndicator (dk:gov:saml:attribute:UserAdministratorIndicator)
Hent OIOSAML Web SSO Profile v2.1.0 (PDF)
OIOSAML 2.1.0 og MitID login
Tjenesteudbydere tilsluttet NemLog-in, som efter go-live i en periode fortsætter på OIOSAML 2.1.0 snitfladen, skal være særligt opmærksomme på, at MitID-brugere potentielt kan logge ind på sikringsniveau Lav (altså uden brug af to-faktor).
Dette er altså i modsætning til NemID-brugere, hvor log-in uden to autentifikationsfaktorer ikke er muligt gennem NemLog-in.
Som tjenesteudbyder er det således vigtigt, at man i autentifikationssvaret fra NemLog-in altid kontrollerer ’dk:gov:saml:attribute:AssuranceLevel’ attributtens værdi.
- Historisk har denne attribut altid haft værdien ”3” for NemID brugere (hvilket indikerer to-faktor log-in)
- Fremadrettet kan den dog antage værdien ”2” for MitID brugere, som kun anvender deres MitID brugernavn og password i en konkret autentifikation.
Ønsker man som tjenesteudbyder ikke, at brugere har adgang til ens tjeneste med ’én-faktor’ login, eksempelvis fordi følsomme oplysninger udstilles, skal man derfor blokere for autentifikationer med værdien ”2” af ovennævnte attribut.
Bemærk, at kontrol af AssuranceLevel-attributtens værdi altid har været en del af NemLog-in’s obligatoriske integrationstest for tjenesteudbydere, og at påvirkningen ved indførsel af MitID er meldt ud på webinarer for tjenesteudbydere senest i marts måned 2021.
De vigtigste ændringer i OIOSAML 3.0
- Der er defineret to nye attributprofiler for henholdsvis personer og professionelle (OCES-specifikke attributter udgår), RID og PID fortsætter med status som forældede.
- Identifiers er baseret på UUID’er, og Subject feltet bærer altid en tjenesteudbyderspecifik identifier.
- Krav til kryptografiske algoritmer og nøglelængder er skærpet.
- Håndtering af ‘levels of assurance’ sker i henhold til NSIS, og der er indført mulighed for at angive et ønsket sikringsniveau i forespørgsler fra tjenesteudbydere.
- Profilen har fået en ny struktur med udgangspunkt i SAML2Int profilen fra Kantara Initiative. Herved er fokus på de normative krav fremhævet, så det bliver lettere at vurdere og teste om en implementering lever op til kravene. Yderligere forklaringer og eksempler udgives i en separat vejledning til profilen, så krav adskilles fra forklaringer.
Ovenstående er ikke en udtømmende liste over ændringer.
Find de gældende OIOSAML profiler her
Bruger I FBRS-privilegier?
Offentlige tjenesteudbydere, der anvender FBRS-privilegier, skal anvende en særlig proces ved overgangen til OIOSAML 3 for at undgå ændringer i eksisterende brugeres rettigheder.
Der er udarbejdet en guide, der beskriver processen for migrering af privilegier. Guiden er en del af OIOSAML 3 dokumentationen, som kan findes via siden for test og dokumentation.