Loading…
Tilbage

OCES-attributter udfases – forbered jer på MitID og NemLog-in broker


OCES-attributter udfases – forbered jer på MitID og NemLog-in broker
Som varslet i nyheder og webinarer betyder overgangen til MitID og det nye NemLog-in en række ændringer for tjenesteudbydere tilsluttet NemLog-in.

Som tjenesteudbyder er det derfor vigtigt, at I tager højde for disse ændringer, så jeres integration til NemLog-in fortsat fungerer, når NemLog-in’s broker har go-live den 19/4 2021.

Med MitID får brugere ikke længere udstedt OCES certifikater. I skal derfor gøre jeres løsning uafhængig af oplysninger, som kun findes i OCES-certifikater. I en overgangsperiode vil NemLog-in fortsat kunne levere de velkendte PID- og RID-numre, så overgangen bliver så smidig som mulig. Øvrige attributter fra OCES-certifikaterne udfases med NemLog-in’s go-live (se nedenfor).

Liste over OCES-attributter, der udfases
Hvis I som tjenesteudbydere er koblet på nuværende OIOSAML 2.0.9 IdP i NemLog-in, skal I forberede jer på, at I med go-live for NemLog-in’s broker ikke længere kan få nedenstående attributter fra NemLog-in. Dette gælder både for brugere, som logger ind med MitID og NemID:

  • 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)

Test jeres integration i testmiljøet
I har nu mulighed for at teste påvirkningen af jeres integration mod NemLog-in i det eksisterende integrationstestmiljø. Log ind i NemLog-in’s Administrationsportal (https://administration.nemlog-in.dk), find jeres it-system, fjern de ovennævnte attributter fra SAML metadatafilen og upload den igen til integrationstestmiljøet - dette kræver at man har rollen "teknisk administrator". Herved vil attributterne ikke længere forekomme i de billetter (SAML Assertions), som udstedes fra NemLog-in til jeres applikation, og det kan testes, hvordan applikationen reagerer.

OIOSAML profiler
OIOSAML profilerne er en vigtig brik i samspillet mellem de 300 offentlige selvbetjeningsløsninger, som er tilsluttet NemLog-in, herunder borger.dk og virk.dk. Profilerne bruges til fødereret log-in og single sign-on (SSO) og sikrer interoperabilitet i implementeringen af SAML2-standarden.

Ved go-live for NemLog-in’s broker vil der være to aktive SAML IdP’er, som kan håndtere brugerautentifikation:

  • Den nuværende OIOSAML 2.0.9 IdP skifter til OIOSAML 2.1.0 snitfladen. OIOSAML 2.1.0 er helt identisk med OIOSAML 2.0.9 profilen bortset fra, at ovennævnte attributter vedr. OCES certifikater udfases.
  • Der tilføjes en ny OIOSAML 3.0.2 IdP. Det er den blivende snitflade, som tjenesteudbydere bør migrere til.

Begge IdP’er vil være aktive indtil NemID udfases, og NemLog-in vil kunne håndtere brugere med både 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.

Se mere om OIOSAML profilerne her https://digst.dk/it-loesninger/nemlog-in/det-kommende-nemlog-in/vejledninger-og-standarder/oiosaml-302/ 

Hvis I vil videre mere
Se eller gense webinaret fra den 14. maj 2020 for tjenesteudbydere om de ændringer, der følger med overgangen til MitID og det nye NemLog-in3.

Hvis I har spørgsmål, er I velkommen til at kontakte Digitaliseringsstyrelsen på kontakt@nemlog-in.dk 

Profilbillede

Opdatering til OIOSAML 2.1.0

Kim Waldorff Østergaard

Spørgsmål til nødvendigheden af, at opgradere OIOSAML.NET fra version 2.0.1 til nyere (evt. 2.1.0).

Det noteres om den nye OIOSAML 2.1.0 at:

Den nuværende OIOSAML 2.0.9 IdP skifter til OIOSAML 2.1.0 snitfladen. OIOSAML 2.1.0 er helt identisk med OIOSAML 2.0.9 profilen bortset fra, at ovennævnte attributter vedr. OCES certifikater udfases.

Vil det strengt taget været nødvendigt at opgradere en eksisterende serviceudbyder fra deres aktuelle version 2.0.1 (ja den er ældre...), til en nyere version (fx 2.1.0) ifm. det som sker omkring den 14. juni med udfasning af OCES attributter m.m.?

Det er ikke min forståelse at det er strengt nødvendigt fra et teknisk synspunkt, da version 2.0.1 fungerer med NemLog-in 2.0.9 IdP'en idag, og ændringer fra 2.0.9 til 2.1.0 alene er udfasning af OCES attributter. Dette er formentligt også årsagen til, at det ikke er frigivet en ny referenceimplementering for netop version 2.1.0, men at den nyeste er 2.0.6 (kilde: https://www.nuget.org/packages/dk.nita.saml20/2.0.6)

//Kim

Hej Kim,

Vær opmærksom på at OIO SAML profilversionen og versionen på referenceimplementeringen ikke følger hinanden, se evt. https://github.com/digst/OIOSAML.Net/blob/master/readme.md - godt nok følger major hinanden.

Nu har jeg ikke lige et samlet overblik over hvilke ændringer der er kommet med mellem 2.0.1 og 2.0.6, men umiddelbart så længe jeres forretning applikation ikke er afhængig af de attributter der udgår, så rent teknisk så burde der ikke være nogen problemer.

Det sagt så er der mulighed for at verificerer det på DevTest4 beta-releaset inden den 16. juni 2021.

//Morten

ændret af Morten D. Bech (26.03.2021)
Profilbillede

PID/RID-oplysninger for bruger, der logger på en 2.10-tjeneste med MitID

Tommy Ravn Jensen

Spørgsmål til overgangen og NemLog-in som "bro":

Scenariet er efter "Go live": En tjeneste, der anvender OIOSAML 2.1.0 + En bruger, der logger på med MitID via NemLog-in. 

Hvad indeholder PID/RID-attributterne i dette tilfælde, hvor brugeren ikke logger på med certifikat? 

Hej Tommy,

PID og RID er to forskellige scenarier, hhv. når en privat person og medarbejder logger ind.

PID er bundet op på CPR, så ved anvendelse af et privat MitID vil attributten indeholde et NemID PID som hidtil. Altså vil tjeneste ikke kunne se forskel.

RID vil kun være muligt for MOCES certifikater og Privat-til-Erhverv identiteter, da det er eneste to typer af erhvervsidentiteter der mulige ved det forestående Go-Live. Privat-til-Erhverv identiteterne vil fortsat benytte PID'et fra privat person bag identiteten som RID uanset om privat NemID eller privat MitID er anvendt til autentifikation.

Det vil iøvrigt også være de samme værdier, der vil være tilgængelig i en OIO SAML 3 Assertion (attributterne har fået nye navne) for at muliggøre migrering.

//Morten

Tak for svaret, Morten!

Hej Morten

Betyder det så (for dette scenarie) at der ikke afleveres en TU-specifik UUID, som MitID ellers ligger op til? Her tænkes at denne UUID ikke vil være ens på tværs af to forskellige TU'er.

/Lenni

Hej Lenni,

Ja, det er korrekt at i denne sammenhæng, altså ved brug af OIO SAML 2 udleveres ikke et unikt UUID for en tjeneste. Det kommer i bund og grund til at for OIO SAML 2 kan vi ikke ændre indholdet af Subject NameID, da det vil bryde bagudkompatibiliteten.

For OIO SAML 3 tjenester vil NemLog-in IdP'en jf. OIO SAML 3 profilen udleverer et NameID der er baseret på et UUID. UUID'et vil for NameID formatet Transient være unikt per session per tjeneste, mens det for Persistent formatet vil være unikt per tjeneste. Det er netop som MitID ligger op til. Det vil være muligt at få udleveret PID og RID igennem attributter i SAML Assertion'en produceret af NemLog-in IdP, hvis disse fremgår af metadata. Det sker for at sikre en migreringsvej for tjenesterne fra OIO SAML 2 til OIO SAML 3.

Det vil (midlertidigt) fortsat være muligt for offentlige tjenester at benytte OIO SAML 2 snitfladen, mens private tjenester altid skal benytte OIO SAML 3 snitfladen. Jeg mener offentlig tjenester har cirka et år fra Go-Live af OIO SAML 3 snitfladen til de skal være ovre på den - men det vil jeg ikke hænges op på.

//Morten