Loginknapper

Gør institutionslogin mere tilgængeligt for brugerne på dit site

Gør adgang med institutions­login tydelig, genkendelig og mere tilgængelig på dit web­site.

Den login­knap som præsenteres her, bygger på RA21-initiativets systematiske arbejde med at forbedre bruger­oplevelsen af adgang med institutions­login til beskyttet online­indhold. Gennem omfattende bruger­test og pilot­forløb er man nået frem til at definere en standard som skaber større klarhed og smidigere adgang for brugerne og gør friktionen for dem minimal.

Den dynamiske udgave af knappen er den implementering vi anbefaler i føderationen. Her på siden finder du baggrund, design­principper og konkret vejledning til implementering.

Bedste løsning: Den dynamiske RA21-knap

Her ser du den knap du bør bruge på sitet for din tjeneste hvis tjenesten udbydes for mere end én institution. Farven (her mørkelilla) kan frit vælges efter dit behov; men den øvrige udformning ligger fast. Knappen viser altid navnet på brugerens institution og fører hende direkte til dens login­tjeneste hvis hun trykker på den; og efter login dér lander hun på dit site, nu autentificeret. Allerførste gang brugeren besøger dit site, vil knappen dog være indstillet på den institution hun hyppigst tilgår fødererede tjenester fra, hvilket ofte også vil være den rigtige ift. din tjeneste. Hvis brugeren ønsker at tilgå din tjeneste fra en anden institution end den knappen peger på, kan hun altid vælge om ved at følge linket under knappen. Valget huskes i browseren, så knappen på dit site til enhver tid vil være indstillet på den institution brugeren sidst har valgt her. Du kan afprøve knappen som er vist her – den virker faktisk.

Koden bag den dynamiske knap opfylder også væsentligt kravene i tilgængeligheds­standarden WCAG 1.2, niveau AA; brugen af knappen vil derfor kunne bidrage til at opnå det niveau af formel compliance for tilgængelighed på dit site. Koden leveres med en note om WCAG-overens­stemmelse blandt sine kommentarer.

Ud over dansk og engelsk under­støtter knappen også færøsk, grønlandsk og islandsk, svarende til føderationens dæknings­område. Sproget følger automatisk sidens eller, som fallback, browserens sprog, medmindre det sættes eksplicit. Institutionens navn vises på det aktuelle sprog hvis det er defineret i føderationens metadata, ellers på engelsk eller dansk. Du kan få demonstreret sprog­varianterne i knappen herover ved at trykke på de indrammede sprog­navne her i afsnittet. (Hver gang du trykker på knappen, nulstilles den dog til dansk).

Hvis din tjeneste ud over fra institutioner også kan tilgås fra NemLog-in/MitID, anbefaler vi meget at du ved siden af den dynamiske knap til institutioner har en statisk udgave af knappen til NemLog-in/MitID; se nedenfor om statiske knapper. Men hvis du alligevel vil bruge den dynamiske knap til både institutioner og NemLog-in/MitID, er det vigtigt at du på dit site konfigurerer knappen til at vise brugeren at NemLog-in/MitID er en mulighed. Det skyldes krav fra Digitaliseringsstyrelsen (gengivet i vilkårene for brug af NemLog-in gennem WAYF) og at NemLog-in/MitID er noget grundlæggende andet end et institutions­login. Du kan ved at trykke her se hvordan knappen ser ud med konfiguration for NemLog-in/MitID; bemærk det særlige udtryk når NemLog-in/MitID er valgt.

Implementering: Sådan gør du

Det er nemt: Du skal bare placere HTML-filen her på web­serveren for din tjeneste og hvert sted på dit site knappen skal vises, indsætte en iframe som henviser til filen. Her skal du sørge for at filnavnet i src optræder med de parametre som passer til din tjeneste og dine præferencer. Længere nede i afsnittet har vi et værktøj så du nemt kan konfigurere de <iframe>-tags du har brug for. Men først gennemgår vi parametrene og de krav knappen stiller til din tjeneste:

To parametre er obligatoriske: rp, som angiver føderations-ID'et (entityID'et eller client_id'et) for din tjeneste, og så ri, hvis værdi skal være en URL som når browseren kalder den, får din tjeneste til svare med en 302 med en autentifikations­anmodning (i enten SAML eller OIDC). Sådan en URL kaldes en request initiator (en “RI”). Hvis din tjeneste bruger WAYFs SSO-proxy som identity provider (“IdP”), kræves intet yderligere end de to parametre for at knappen fungerer. Er din tjeneste derimod på SSO-protokol­niveauet forbundet til udvalgte institutioner (har en særskilt SSO-konfiguration for hver institution), så kan knappen kun fungere hvis din tjenestes RI kan modtage en parameter med føderations-ID'et (entityID'et) for en bestemt IdP og stile sit 302-svar til den IdP. Hvis din tjeneste fungerer på den måde, skal du i hver iframes src-værdi også bruge den tredje parameter returnIDParam, hvis værdi er navnet på den URL-parameter din RI fortolker som angivelse af ønsket IdP.

Øvrige parametre: Med color kan du angive knappens farve, i formatet #HHHHHH. Af hensyn til bruger­venligheden og kravene i WCAG bør du undgå farver hvis kontrast med hvid er mindre end 4,5:1. Parameteren nl skal sættes til true hvis din tjeneste er tilsluttet NemLog-in/MitID, og du ønsker at den IdP skal kunne vælges med den dynamiske knap. Vi anbefaler dog meget at du i stedet bruger en statisk knap til NemLog-in/MitID, ved siden af den dynamiske til institutioner. Parameteren another sat til true medfører at linket for institutions­valg under knappen skal vises selv i det sjældne tilfælde hvor knappen ingen institution peger på og derfor har teksten Få adgang via din institution; i den situation vises linket i udgangspunktet ikke, og tryk på knappen fører brugeren til siden for valg af institution. Parameteren lang angiver med ISO 639-1 knappens sprog; og udelades den, følger knappens sprog sidens hvis den har ét, og ellers browserens.

Her følger nu værktøjet til konfigurering af den dynamiske knaps iframe:

Hvis man vil bruge en anden tjeneste for valg af IdP

Afslutningsvis gør vi opmærksom på at knappens kode bruger WAYFs discovery-tjeneste (tjeneste for valg af IdP), men at det er muligt at bruge en anden. Knappen kræver dog af en discovery-tjeneste at den kan svare uden bruger­inddragelse hvis den kaldes med isPassive=true – og at den implementerer de her to policies (og forstår dem som værdier af parameteren policy): v2, som indebærer at 302-svaret skal omfatte en JSON med entityID og visnings­navne for den fundne IdP som værdi af en parameter entityIDJSON; og så mindthegap,v2 med samme betydning plus signal om at en RA21-knap har afsendt discovery-anmodningen.

Statiske RA21-knapper: Hvis det ikke kan være anderledes

Man kan også bruge en statisk RA21-knap: en som aldrig skifter tekst eller udseende i øvrigt. Sådan en kræver hverken JavaScript eller iframes og er teknisk enklere end den dynamiske knap – og i to situationer den rigtige løsning:

Hvis din tjeneste kun udbydes for én institution, bør knappen fikseres til den institutions login­tjeneste og med fast tekst henvise til institutionen – brugeren bør ikke skulle fremsøge sin institution hos en discovery-tjeneste ved hvert besøg. Og hvis din tjeneste kan tilgås fra NemLog-in/MitID, bør den login­mulighed have sin egen statiske knap, ved siden af den dynamiske knap til institutioner: NemLog-in/MitID er ikke nogen institution, og derfor er det ikke optimalt for brugerne hvis man skjuler den login­mulighed bag et signal for adgang med institutions­konto.

Du bør så vidt muligt implementere statiske knapper med HTML/CSS – det giver så langt de bedste tilgængeligheds­egenskaber. Men hvis du er låst i et framework som ikke tillader andet, kan du i stedet bruge en grafisk udgave af knappen.

Når du udformer en statisk RA21-knap, er det lidt forskellige ting du skal tage stilling til, afhængigt af om din tjeneste udbydes for flere institutioner eller kun for en enkelt. Derfor har vi herunder to forskellige “fabrikker” du kan fremstille de nødvendige knapper med, en til hver situation:

Hvis din tjeneste udbydes for én institution eller bruger NemLog-in

Her kan du selv fastsætte teksterne på knappen. Navnet for institutionen (i nederste linje) bør være officielt og helst det samme som bruges i føderationen; og teksten i øverste linje bør af hensyn til genkendelighed ikke afvige meget fra Få adgang via. Hvis du ikke bruger en grafisk udgave af knappen, kan du i hver linje definere sprogvarianter af teksten. Farve og “luft” omkring knappen kan indstilles frit. I den ikke-grafiske udgave skal du kunne levere en request initiator-URL. Bruger din tjeneste NemLog-in, er det også “fabrikken” her du kan fremstille den anbefalede statiske knap med:

Hvis tjenesten udbydes for flere institutioner

Hvis din tjeneste udbydes for flere institutioner, men den dynamiske knap er vanskelig at integrere på dit site, kan en statisk RA21-knap være mere fremkommelig og vil stadig være bedre end andre signaler for institutions­adgang.

RA21-pilotforløbet viste imidlertid klart at det øger brugernes forståelse og tillid til knappen at have institutions­navnet stående på den. Og hvis du bruger en anden discovery-tjeneste end WAYFs, vil en statisk knap også medføre at brugeren skal vælge sin institution på ny hver gang hun besøger din tjeneste. Så brug den dynamiske hvis du overhovedet kan.

En statisk RA21-knap for en tjeneste som udbydes for flere institutioner, skal blot vise standardens generiske tekst “Få adgang via din institution” på relevante sprog. I fabrikken herunder kan du fremstille den slags knapper i valgfri farve og skal i den ikke-grafiske udgave blot kunne levere en request initator-URL. Bruger din tjeneste også NemLog-in, kan du godt få omtalt muligheden på knappen og dermed bruge én knap til både NemLog-in/MitID og til institutioner; men vi anbefaler som nævnt at du bruger én knap til institutioner og en anden til NemLog-in/MitID (som kan fremstilles i fabrikken ovenfor). Her følger fabrikken for statiske knapper for flere institutioner:

Designprincipper: Hvad er vigtigt?

Med en dynamisk RA21-knap på sitet for sin tjeneste har man implementeret de anbefalinger som skaber en så god og friktions­løs en oplevelse som muligt af login med institutions­konto:
  • Der skal være én tydelig og genkendelig vej til institutions­adgang.
  • Første login skal være en enkel “find din institution”-proces.
  • Brugeren skal helst kun finde sin institution én gang.
  • Brugeren skal stadig have kontrol over det huskede valg.
  • Institutions­søgningen skal minimere valg­muligheder og usikkerhed.
  • Tilgængelighed er en del af login­oplevelsen.

Og som vi har set, kan man – hvis man ikke vil bruge standard­knappen – alligevel nå nogle af målene ved at låne så mange elementer fra den som muligt, fx med en statisk, men dog genkendelig RA21-knap. Blot det at bruge standard­formuleringer som Få adgang via din institution og vores generiske symbol for institutions­login giver en bedre login­oplevelse. Men ét princip, som desværre ofte overses, vil vi fremhæve som afgørende:

Den gode loginknap nævner hverken WAYF eller leverandøren

Undgå at nævne WAYF eller institutionens tekniske leverandører i tjenestens bruger­grænseflade – hverken i tekst eller med logo.

For identitets­ansvarlige hos tjeneste­udbydere og institutioner er WAYF et vigtigt navn at kende. For slut­brugeren er det ikke: Hun kender tjenesten hun vil ind på, og hun kender sit institutions­login. Mere behøver hun ikke vide for at komme ind. Nævner man WAYF, tvinger man hende til at forholde sig til endnu en ting, som intet betyder for hende, og gør vejen ind længere – ikke i klik, men i tanker.

Det er også med til at udbrede en misforståelse: En del brugere tror at WAYF er et selvstændigt login eller en selvstændig digital identitet med egne bruger­konti. Men det er en kategori­fejltagelse: WAYF er et rør mellem tjeneste­udbydere og institutioner, og der findes ingen “WAYF-identitet” eller noget “WAYF-login” ved siden af brugerens institutions­identitet. Følgen er bl.a. at brugere henvender sig til WAYF for at få rettet fejl som kun deres institution kan rette – fx en glemt adgangs­kode eller en forkert e-mail­adresse – og bliver sendt videre i stedet for at få hjælp.

Af samme grund hører navne på tekniske leverandører heller ikke hjemme på knappen. Det er institutionen der udsteder og forvalter brugerens digitale identitet – ikke den leverandør institutionen tilfældigvis har valgt til at implementere eller drive den. Hvilken teknik der ligger bag, er uden betydning for brugeren, og leverandørens navn på knappen er ikke meget andet end skjult reklame. Det holder heller ikke: Skifter institutionen leverandør, er knappen pludselig forkert selv om brugerens identitet er den samme. Kort sagt: Nævn den identitet brugeren kender – institutionen eller MitID – ikke den teknik der leverer den.

Det samme gælder MitID, som WAYF også formidler login med. Står der “WAYF” på knappen, ligner WAYF et alternativ til MitID – mens det i virkeligheden er MitID brugeren logger ind med.

Endelig holder en knap uden WAYFs navn længere. Mange tjenester bruges også af udenlandske brugere via eduGAIN, og for dem siger navnet WAYF ingenting. En tjeneste kan også være med i flere føderationer eller skifte føderation. En knap der taler om brugerens institution, er rigtig i alle tilfælde.

Det er derfor med god grund at RA21-designet sætter navnet på brugerens institution på knappen og holder føderationen ude af syne: Det gør brugerens vej ind enklere.