UI Text Box | ||||
---|---|---|---|---|
| ||||
Udfasning af SSOproxy og Atlas integrationer i Unilogin Vi har beskrevet processen for overgangen til de nye snitflader her: Overgang fra SSOproxy og ATLAS til SAML eller OIDC |
Ofte stillede spørgsmål
Teknisk FAQ Uddrag medtager
Info | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Der er to valgmuligheder for at tilslutte en tjeneste; OIDC eller SAML. I dette afsnit forklares processer og forudsætninger i forbindelse med tilknytning af tjeneste. SAML:Eksterne tjenester kan blive tilsluttet Unilogin Broker såfremt de tjener et relevant formål i forhold til skoler og institutioner og forudsat at de opfylder nedenstående tekniske krav. SAML-standarden er et XML-baseret rammeværk til udveksling af sikkerhedsinformationer mellem forskellige online parter. Sikkerhedsinformationen udtrykkes i form af portable SAML påstande (assertions), som er digitalt signerede XML-strukturer, der udveksles mellem de kommunikerende parter. SAML-standarden omfatter tillige en web single sign-on profil (Web SSO), som beskriver mekanismer for udvekslingen af SAML assertions i et web-miljø, således at en tjenesteudbyders web-server kan opnå autentificering af en bruger gennem omdirigering af brugerens browser via en identitetsyders web-server. Det er også i autentificeringsprocessen muligt at sende information om brugeren i form af attributter, som fx kan anvendes til autorisation. Tjenesteudbyderen kaldes i SAML-sammenhæng en SP (Service Provider) mens identitetsudbyderen kaldes en IdP (Identity Provider). Forud for at kommunikation med SAML Web SSO kan finde sted er det nødvendigt at udveksle metadata for tjenesteudbyders SAML SP og Unilogin Broker. Metadata er beskrevet i SAML standarden og fastlægger de involverede certifikater og andre informationer nødvendige for kommunikationen, såsom end-points for SP’ens Assertion Consumer Service og IdP’ens Single Sign On Service. Tilslutning sker i praksis tilslutning til Unilogins eksterne testmiljø. Det er en forudsætning at tjenestens SAML SP er blevet tilsluttet og godkendt her inden den kan sættes i drift i Unilogins produktionsmiljø. Kommunikation af ønsket sikringsniveauØnske om et givet sikringsniveau kommunikeres fra tjenestens SAML SP til Unilogin Broker i <AuthnContextClassRef> i SAML <AuthnRequest>. Værdierne skal følge specifikationen af Unilogin-føderationens sikringsniveauer. Tjenesten modtager de opnåede sikringsniveauer som attributter i <Assertion>-delen af SAML <Response> . Data medsendt fra Unilogin BrokerUnilogin Broker sender et tjenestespecifikt pseudonym for den indloggede bruger i <NameID>, eksempelvis "G-91552a74-b560-4057-ade9-083b94da07e6". Derudover medsendes følgende attributter i <Assertion>: OIDC: OBS | ||||||||
Attribut-navn | Værdi | |||||||
dk:unilogin:uniid | Unilogin brugernavnet af hensyn til bagudkompatibilitet (Udfases i takt med udbredelsen af pseudonymisering i Unilogin) | |||||||
dk:unilogin:aktoertype | Brugerens valgte aktørtype i Unilogin ud fra de registrerede tilknytninger i SkoleGrunddata. | |||||||
dk:unilogin:loa | Sikringsniveau i Unilogin (EnFaktor, VoksenVerificeret eller ToFaktor) | |||||||
dk:gov:saml:attribute:AssuranceLevel | Sikringsniveau i forhold til OIOSAML 2.0.9 afledt af ovenstående Unilogin sikringsniveau (2, 2 eller 3) | https://data.gov.dk/concept/core/nsis/loa | Sikringsniveau i NSIS 2.0.1 / OIOSAML 3.0 sikringsniveau (Low, Substantial eller High) (Indføres i takt med udbredelsen af NSIS i IdP'er)