Sidehistorik

til IdP'er i Unilogin-føderationen

Formelle krav

NSIS

IdP'er som benyttes af voksne, skal være NSIS anmeldt. For at dette kan efterprøves skal det EntityID som er anvendt i metadata være identisk med det EntityID der fremgår af Digitaliseringsstyrelsens NSIS positivliste (https://digst.dk/it-loesninger/standarder/nsis/). 
Læs mere om NSIS i Unilogin her Lokal IdP - NSIS anmeldelse og øvrig cybersikkerhed

EntityID står under felter Issuer i SAMLRequests og SAMLResponses. Bemærk at indholdet i EntityID og Issuer skal være helt ens for at STIL kan knytte NSIS anmeldelsen til en IdP. 

Blanket: Tilkobling af IdP til eksternt testmiljø

Udfyld blanketten neden for omkring IdP for at få denne tilkoblet det eksterne testmiljø for Unilogins broker.
I bedes oprette en sag via denne Kontaktformular og vedhæfte blanketten med de udfyldte oplysninger.

Den videre dialog med supporten vil foregå via sagshåndteringssystemet Jira.

Tilkobling af lokal IdP v1_1.docx

Tekniske krav

Opsætning af lokal IdP

Unilogin understøtter SAML 2.0 til login og autentificering af brugere for web-baserede applikationer i et single sign-on miljø og protokolprofilen for OIOSAML 3.0. Lokale IdP'er

i Unilogin føderationen skal derfor følge denne profil, herunder eksklusiv anvendelse af OCES3 systemcertifikater, der udstedes via MitID Erhverv. Desuden skal IdP'en

understøtte Unilogin-føderationens sikringsniveauer og håndtere login-faktorer og -kommunikation i overensstemmelse med disse. 

En IdP tilsluttes ved at der udveksles metadata mellem IdP'en og Unilogin Broker. Metadata er beskrevet i SAML standarden og fastlægger de involverede certifikater og andre informationer nødvendige for kommunikationen, såsom

endpoints for IdP’ens Single Sign On Service og Single Logout Service.

CVR numre 

CVR numre på IdP'ens ejer skal stemme overens med CVR registeret i IdP'ens OCES3 certifikat.

Kommunikation af brugers identitet

Unilogin Broker medsender brugernavn til IdP'en i <Subject> i SAML's AuthnRequest, hvis det er blevet indtastet i forbindelse med discovery processen i Unilogin Broker. F.eks. kan dette være "bruger@domain".

IdP'en skal som udgangspunkt sende

identifikationen af den indloggede

bruger til Unilogin Broker i SAML's <NameID>. Identifikationen skal være kendt i Unilogin Broker

via import til SkoleGrunddata. Gyldige værdier er på nuværende tidspunkt brugerens

Uniid eller CPR-nummer. Sendes CPR-nummer skal det sendes i et OIOSAML-attribut efter nærmere aftale. Uniid eller CPR nummer skal være krypteret. 

Beskyttelse af personhenførbare data

Ved tilslutning af en lokal IdP i Unilogin Broker, er der krav om at requests og responses sendt til Broker er krypteret, for at data som sendes med ikke kan fanges af en mellemmand, og misbruges.

Hvis kravet om krypteret kommunikation med Unilogin Broker ikke overholdes, vil login blokeres indtil at kravet opfyldes.

Kommunikation af ønsket sikringsniveau

Sikringsniveauer kommunikeres

fra Unilogin Broker

til IdP i <AuthnContextClassRef>

i autentificeringsforespørgslen. Svar fra IdP'en sendes i attributter som specificeret i dokumentationen for Unilogin-føderationens sikringsniveauer.

Verificering af succesfuld tilkobling

Når en lokal IdP er blevet oprettet i Unilogin Broker, så er der krav verificering af følgende:

1. Der kan foretages succesfuldt
   1. login
   2. logud
2. Kommunikationen er krypteret
3. EntityID/Issuer afspejler det som der er blevet registreret i NSIS Positivlisten
   1. Dette gælder ikke for IdP'er som kun er til elever

Ovenstående kan bekræftes ved at sende SAML-traces i supportsagen

.