Her kan de læse om

arkitekturen, der er baseret på Unilogin Broker, der kobler hhv. tjenester og IdP'er, så brugeren kan logge ind.

SkoleGrundData leverer alle nødvendige data om personer og deres roller på institutionerne. En person kaldes formelt en entitet og en samling af personens relaterede roller definerer en aktør.

På baggrund af  disse data fastlægger Unilogin, jf. nedenstående arkitektur, hvilke elektroniske identiteter en entitet får i Unilogin og hvilke aktører, der er knyttet op på disse. Desuden fastlægges der i løsningen, hvordan en given identitet kan autentificeres.

En identitet med samlingen af aktører og autentificerings-muligheder kaldes et brokerid. Den primære opgave i registreringsdelen af SkoleLogin-projektet er således en opbygning af et broker-register på baggrund af data fra SkoleGrundData.

Et eksempel på et brokerid: En person er kontakt for en række børn. Alle rollerne som kontakt og CPR-nr samles i et brokerid. Entiteten kan nu logge ind med NemID og identificeres i Unilogin med et brokerid med aktøren "kontakt" .

En af autenticeringsmulighederne i Unilogin brokeren er Unilogins egen IdP. Løsningen administrerer akkreditiverne i Unilogin IdP'en og deres relationer til brokerid'er. I praksis oprettes akkreditiverne i Unilogin IdP'en i første omgang af de eksisterende UNI-Login registreringsprocesser, hvor skolerne i dag leverer data til STIL via en webservice, WSAImport (WS10). Dette sker i Skolegrunddata.

Opgaven i Unilogin begrænser sig derfor til at oprette og knytte Unilogin IdP'ens ID, kaldet UPID (Unilogin Personlig ID), til et eksisterende akkreditiv fra SkoleGrunddata og skabe relationen til identiteter i broker-registeret.

Flow for vedligehold af Broker-registeret

En event-strøm med relevante data til broker-registeret leveres af SkoleGrunddata-projektet ud fra de eksisterende UNI-Login registreringsprocesser på basis af wsiEKSPORT.

På baggrund af disse data besluttes der om en entitets aktør-tilknytninger i elevregisteret skal oprettes med et nyt brokerID eller knyttes til et eksisterende. Der oprettes et nyt brokerID, når entiteten registreres med en ny aktør som hhv elev, medarbejder/ekstern eller kontakt.

ID-referencer fra andre identitetsudbydere

Analogt til tilkoblingen af UPID til brokerID'er skal broker-administrationen udstille en service, hvor eksterne identitetsudbydere, der er tilsluttet føderationen, kan til- og frakoble egne ID'er til brokerID'er. Dette skal ske i henhold til et regelsæt, som identificerer de relevante brokerID'er, hvor det lokale ID skal tilkobles. Ved tilslutning af en identitetsudbyders IdP til føderationen skal der defineres et scope for hvilke institutioner og aktørtyper ("medarbejder/ekstern", "elev" eller "kontakt"), der kan anvende IdP'en. Derudover skal der identificeres en nøgle, der er kendt i SkoleLogin-føderationen, f.eks. CPR eller UNI-ID.

F.eks. kunne en kommune-IdP koble lokale ID'er til brokerID'er, der indeholder aktøren "medarbejder" for institutioner i den pågældende kommune, hvor entiteten er identificeret med CPR-nummer.

Relation til Fællesoffentilig arkitektur for brugerstyring

Et brokerID svarer til en identitet (eID) i den fællesoffentlige arkitektur for brugerstyring, suppleret med afledte referencer fra andre identitetsbrokere (KommuneID, PID/RID, CPR, UNI-ID).

Kilde: https://data.gov.dk/model/concept/usermanagement.htm