Krav til brugeren
Som bruger af Unilogin skal du beskytte dit Unilogin tilsvarende med de almindelige regler der gælder for Elektroniske Identifikationsmidler.
Dit Unilogin består af dit brugernavn og dit password. Du skal overholde nedenstående.
o Du må alene anvende dit Unilogin i overensstemmelse med udstederens politikker (herunder politikker for brug og evt. længde af kodeord)
o Du må ikke overdrage dit Unilogin til andre
o Du skal give fyldestgørende og korrekte svar på alle anmodninger om information i ansøgningsprocessen. Ansøgningsprocessen varetages af den institution du er tilknyttet til.
o Du skal tage rimelige forholdsregler for at beskytte dit Unilogin (herunder ved evt. sikkerhedskopiering).
o Du skal omgående anmode den Institution du er tilknyttet til om spærring af dit Unilogin i tilfælde af kompromittering eller mistanke om kompromittering af oplysningerne i dit Unilogin.
o Du skal omgående anmode den Institution du er tilknyttet til om fornyelse af dit Unilogin, hvis indholdet af disse ikke længere er i overensstemmelse med de faktiske forhold (herunder oplysninger afgivet under registreringsprocessen, som indgår i Elektroniske Identifikationsmidler).
Lovgivning og juridiske aspekter ved databehandlingen i Unilogin
Unilogin behandler persondata. Dermed skal det være klart defineret, hvem der er dataansvarlig henholdsvis databehandler for de persondatabehandlinger, der foretages.
Den dataansvarlige er ansvarlig for overholdelsen af persondataloven.
Databehandleren kendetegnes ved kun at behandle personoplysninger på vegne af (efter instruks fra) en dataansvarlig. Databehandleren behandler således aldrig personoplysninger til egne formål og må derfor ikke bruge de overladte oplysninger til andet end udførelsen af opgaven for den dataansvarlige.
I forhold til persondatareglerne er skolerne dataansvarlige for databehandlinger i Unilogin og STIL er databehandler. Det er således skolerne, der har ansvaret for de data, der er UNI-login, herunder deres kvalitet og hvem der har adgang til at behandle dem.
Dette gælder også, når persondata via UNI-login og en af skolen godkendt dataaftale (instruks) stilles til rådighed for skolernes indkøbte tjenester. Skolerne skal således, som dataansvarlig, indgå databehandleraftaler med alle de tjenester, der behandler personoplysninger på skolernes vegne, også i de tilfælde hvor tjenesterne får skolernes personoplysninger fra Unilogin.
Bemærk i denne forbindelse, at der i mange tjenester opbevares personoplysninger, ud over de oplysninger der evt. er hentet fra Unilogin
Derimod skal skolerne ikke indgå en skriftlig databehandleraftale med STIL. Dette krav er allerede opfyldt med Vejledningslovens § 15 g, som regulerer de forhold, der alternativt ville være krævet i en skriftlige databehandleraftale. Vejledningsloven §15g erstatter med andre ord en databehandleraftale mellem skolen og STIL.
Samlet understøttes dataflowet juridisk som skitseret nedenfor:
Se mere om databehandleraftaler hos Datatilsynet (Der findes flere skabeloner for databehandleraftaler tilgængelig på nettet.)
Se evt. Vejledningsloven på www.retsinformation.dk
Se et eksempel på en skabelon til indgåelse af databehandleraftaler på www.kombit.dk
For en uddybning af de juridiske aspekter ved databehandlingen i UNI-login se her: stil.dk
I de situationer, hvor Undervisningsministeriet anvender data fra institutionernes registreringer i Unilogin til statistiske formål (eller lovbestemt afrapportering og analyse) sker det via en videregivelse, hvorefter Undervisningsministeriet ved STIL er dataansvarlig.
Bliv oprettet som Udbyder og få adgang til Tilslutning
Inden du kan få adgang til Tilslutning skal man som Udbyder følge nedenstående 3 punkter.
- Det er en forudsætning at man er oprettet som Udbyder i STIL's udbyderregister for at man bestille adgang til en STIL Service. STIL skal bruge:
- Navn på Institution, CVR nummer og P-nummer (P-nummer er vigtig hvis man f.eks. har flere produktionsenheder/matrikler)
- Oplysningerne skal sendes via denne Kontaktformular
- Emnefeltet i sagen skal registeres som 'Opret Udbyder'
- Beskriv
- Hvilken service i tilbyder
- Hvem er målgruppen
- Hvordan er indholdet undervisningsrelateret
- Afvent en bekræftelse fra STIL om man som Virksomhed, organisation, institution er oprettet.
- Herudover skal du og andre relevante medarbejdere have rettigheden "Tilslutning: Ret til at administrere aftaler på tilslutning.stil.dk" for at kunne til logge på Tilslutning.stil.dk med en MitID erhvervsidentitet. Læs her hvordan du selv bestiller rettigheden.
- Herefter kan du anvende Tilslutning.stil.dk.
SkoleGrunddata
Siden beskriver en forældet Unilogin grænseflade
Unilogin autentificering
Unilogin er en tjeneste til adgangsstyring og brugeradministration for udbydere af net-baserede applikationer i uddannelsessektoren. Dette dokument beskriver den tekniske grænseflade, som applikationerne skal integreres med, i relation til adgangsstyring med Unilogin.
Hvordan virker det?
Når en applikation ønsker at logge en bruger ind via Unilogin, sker det ved, at applikationen viderestiller brugerens browser til en Unilogin-server.
Brugeren vil her blive præsenteret for loginformularer, hvor først brugernavn og derefter adgangskode (ikoner for 0. til 3. klasse og tegn for resten) indtastes:
Hvis brugeren godkendes, viderestiller Unilogin brugerens browser tilbage til applikationen sammen med en billet, der beviser, at brugeren er godkendt. Billetten skal valideres af applikationen, som derefter overtager ansvaret for brugerens session. Princippet er illustreret nedenfor:
- Brugeren kontakter applikationen
- Applikationen viderestiller til Unilogin
- Unilogin viderestiller tilbage med en billet
Unilogin understøtter Single Sign On. Hvis brugeren i løbet af sin browser-session allerede tidligere er logget ind i Unilogin, vil vedkommende ikke igen blive afkrævet brugernavn og adgangskode. Brugeren vil automatisk blive godkendt af Unilogin-serveren og blive viderestillet tilbage til applikationen med en billet. Denne funktionalitet gør det muligt at give brugeren en oplevelse af, at de forskellige Unilogin applikationer er integrerede. Det er muligt at undgå denne funktionalitet ved at benytte Single Login i stedet for Single Sign On. I så fald vil brugeren altid blive afkrævet et password ved adgang til tjenesten.
Hvordan identificerer applikationen sig overfor serveren?
Applikationen identificerer sig overfor Unilogin-serveren ved at sende parameteren ”id” med i viderestillingen, f.eks. kunne applikationen viderestille til:
https://sso.emu.dk/unilogin/login.cgi?id=test
Hver applikation har et unikt ”id” med en tilhørende unik fælles hemmelighed, som er aftalt på forhånd mellem producenten og Styrelsen for It og Læring.
Ofte er returURL ligeledes aftalt offline. Visse applikationer har imidlertid brug for, at Unilogin dynamisk kan viderestille brugeren tilbage til forskellige sider i applikationen. Dette kan afstedkommes ved at applikationen medsender parametrene ”path” og ”auth” i den originale viderestilling.
Parameter | Beskrivelse |
id | Hver applikation har et unikt ”id” |
secret | Unik fælles hemmelighed, som er aftalt på forhånd mellem producenten og Styrelsen for It og Læring |
returURL | Er normalt aftalt på forhånd, men kan medsendes dynamisk i ”path” |
path | Indeholder returURL. Beregnes som URI_ESCAPE(BASE64(returURL) |
auth | Et fingeraftryk, der autentificerer ”path” Beregnes som MD5(returURL+secret) |
Eksempel på viderestilling med dynamisk returURL:
https://sso.emu.dk/unilogin/login.cgi?id=test&path=aHR0cDovL3d3dy5lbXUuZGsvYXBwbA%3D%3D&auth=59169cb39fab40cb0ad6ade6a6eb491e
I eksemplet er ”retur-URL” http://www.emu.dk/appl og secret er ”abc123”.
Beregningerne bliver således:
path = URI_ESCAPE(BASE64(”http://www.emu.dk/appl”)) = URI_ESCAPE(”aHR0cDovL3d3dy5lbXUuZGsvYXBwbA==”) = ”aHR0cDovL3d3dy5lbXUuZGsvYXBwbA%3D%3D”
auth = MD5(”http://www.emu.dk/applabc123”) = “59169cb39fab40cb0ad6ade6a6eb491e”
Hvordan ser billetten ud?
Billetten er indkodet i URL’en, der viderestilles tilbage til. Den kunne f.eks. se således ud:
http://www.emu.dk/appl?user=testuser×tamp=20030505125952&auth=5e55280df202c8820a7092746b991088
Der indgår altid følgende tre parametre i viderestillingen:
Parameter | Beskrivelse |
user | Brugernavnet på den godkendte bruger. I eksemplet er brugernavnet ”testuser”. |
timestamp | Tidsstempel på formatet YYYYMMDDhhmmss, som angiver tidspunktet for billettens udstedelse i UTC (GMT). |
auth | Et fingeraftryk, der autentificerer ”user” og ”timestamp”. Fingeraftrykket er angivet hexadecimalt og beregnes som MD5(timestamp+secret+user), hvor ”secret” er en forud aftalt hemmelighed mellem applikationen og Unilogin-serveren. |
Når applikationen modtager billetten bestående af disse parametre, skal applikationen verificere, at fingeraftrykket er korrekt og at billetten ikke har været benyttet før.
Korrektheden af fingeraftrykket verificeres ved, at applikationen genberegner MD5(timestamp+secret+user). Værdien skal være den samme som modtaget i ”auth”-parameteren. I ovenstående eksempel er der benyttet en fælles hemmelig med værdien ”abc123”. Fingeraftrykket beregnes derfor til:
auth = MD5(”20030505125952abc123testuser”) = 5e55280df202c8820a7092746b991088
At billetten ikke har været benyttet før, kan verificeres ved at gemme brugte billetter. Alternativt kan man acceptere billetter, der er udstedt inden for et kortere tidsvindue, f.eks. 60 sekunder. Vinduet må ikke være kortere end den tid, det tager at viderestille brugerens browser. Bruger man tiden til at afgøre billettens validitet, er det vigtigt, at applikationens ur går rigtigt. Unilogin er tidsmæssigt synkroniseret mod centrale NTP-servere på Internettet.
Hvis ”auth” kan valideres og billetten ikke er genbrugt, er ”user” autentificeret og applikationen kan nu oprette en session med brugeren, f.eks. ved at udstede en session cookie.
Hvordan logger man ud af Unilogin?
Unilogin understøtter Single Sign On, og dermed er det ikke tilstrækkeligt at en applikation ved logout blot nedlægger sin egen session med brugeren. Hvis brugeren kontakter applikationen igen, vil vedkommende blot komme direkte ind igen uden at skulle forny sit login, da Unilogin stadig vil udstede en billet på baggrund af det tidligere login.
Det er derfor nødvendigt at logout-processen foruden at nedlægge applikationens egen session med brugeren også omstiller til Unilogin, således at brugerens Unilogin session også kan nedlægges.
URL’en der skal henvises til ved logout er:
Bemærk, at Unilogin ikke automatisk logger brugeren ud af øvrige applikationer, som brugeren måtte være logget ind i direkte eller indirekte i løbet af sin session. Den eneste sikre måde at komme ud af alting på er at lukke browseren. Det er derfor en generel anbefaling ved brugen af Unilogin Single Sign On at opfordre brugeren til at lukke browseren efter brug.
Single Login og gruppelogin
Hvis applikationen ønsker fuld kontrol over login-processen, kan Single Login anvendes i stedet for Single Sign On. Konsekvensen er, at brugeren altid vil blive afkrævet et password ved adgang til tjenesten, hvilket kan ødelægge oplevelsen af integrationen af tjenester i f.eks. en elevportal.
Single Login kan f.eks. anvendes til at implementere gruppelogin ved at lade deltagerne logge ind enkeltvis med Single Login, mens deres identiteter sammenknyttes i applikationen.
For at anvende Single Login skal man benytte serveradressen sli.emu.dk frem for sso.emu.dk. På alle andre områder er dokumentationen den samme.
Autorisation/Adgang
Autorisation af om en bruger har adgang til en given tjeneste kontrolleres generelt i UNI•Login ved at tjenesteudbyderen kalder webservicen ws05/wsiAUTOR. For enkeltstående tjenester kan autorisation alternativt ske implicit via konfigurationen af SSO Proxy, idet applikationens id bindes direkte til en specifik tjeneste. Licenser, d.v.s. hvilke grupperinger i UNI-Login der er autoriseret til at måtte tilgå en tjeneste, administreres via webservices ws03/wsaLICENS eller for mindre anvendelser via brugergrænsefladen GivAdgang: http://givadgang.uni-login.dk.
GivAdgang gør brug af ws03/wsaLICENS og giver derfor samme muligheder for administration af adgange. En ny tjenesteudbyder - med behov for adgangsadministration - vil starte med GivAdgang. Hvis GivAdgang ikke giver tilstrækkelige muligheder eller hvis der ønskes integration med tjenesteudbyderens andre administrative læsninger, kan man overgå til direkte administration via ws03/wsaLICENS. Dette kan ske uden at skulle ændre i allerede etablerede adgange.