Af Mikkel Hald, 28/10/20
Brugeroplevelsen af fødereret login varierer meget fra webtjeneste til webtjeneste — med forskellige grafiske udtryk og forskellige steps brugerne skal igennem. I mange tilfælde er brugeroplevelsen suboptimal, og den tekniske integration er ikke altid lige vellykket.
For at forløse og afhjælpe den situation har det såkaldte RA21-initiativ – et konsortium af forlag, medicinalvirksomheder og føderationsteknikere – for nylig undersøgt hvad der er afgørende for en god og seamless brugeroplevelse af fødereret login, og gennemført omfattende pilotprojekter og brugertest. Resultatet er blevet et sæt anbefalinger – en empirisk funderet standard for hvordan fødereret login bør præsenteres og fungere på websitet for en tjeneste. Anbefalingerne er publiceret af den amerikanske National Information Standards Organization (NISO) og har fået en referenceimplementering under initiativet SeamlessAccess.org, som er en udløber af RA21.
SeamlessAccess-implementeringen af RA21 er veludviklet og er begyndt at nyde en vis udbredelse. Men den kan også være et stort stof at skulle overskue og kan muligvis udfordre fremtidige default-sikkerhedsindstillinger i browserne. Derfor har WAYF udviklet en langt mere lightweight RA21-implementering og opfordrer hermed føderationens tjenesteudbydere til at bruge dén – enten as-is eller som inspiration. WAYF anbefaler alle tjenesteudbydere at indarbejde standarden.
WAYFs RA21-implementering har form af en statisk HTML-side på få linjer som skal indlejres på tjenestens site i en iframe. Siden viser en simpel login-knap med standardens symbol for institutionsadgang efterfulgt af en tekst som Log ind via din institution (Access through your institution hvis browsersproget er engelsk):
Sådan ser knappen ud første gang brugeren besøger tjenestens website. Når hun trykker på den, beder WAYF hende vælge sin institution på den velkendte discovery-liste over mulige loginsteder i WAYF. Herefter logger hun ind ved sin institution og lander til sidst på tjenestens site igen, nu logget ind eller afvist – sådan som fødereret login nu engang foregår. Men knappen er anderledes næste gang hun besøger sitet for at logge ind: Nu står der noget i stil med Log ind via X på den, hvor X er navnet på den institution hun valgte ved sit første besøg. Og når hun trykker på den, ser hun straks efter loginsiden hos X og skal ikke først vælge X på en liste for at komme til loginsiden. Under knappen er der nu også et centreret link Vælg en anden institution (eller Access through another institution), så hun har mulighed for at vælge om:
Brugerens valg af institution eller loginsted gemmes lokalt i hendes browser under tjenestens domæne. På den måde er det kun tjenesteudbyderen der har adgang til viden om hvilken institution brugeren har valgt. Mht. “cookie-bekendtgørelsen” foreligger her formentlig en nødvendig lagring i brugerens terminaludstyr, som derfor ikke kræver hendes samtykke.
WAYFs HTML-fil er klar til brug hos tjenesteudbyderne som den er. Som tjenesteudbyder skal man blot inkludere filen i en iframe på de sider hvorfra brugeren skal kunne påbegynde fødereret login til tjenesten. I praksis en JavaScript-linje som den her på tjenestens landing pages:
document.querySelector("#mindthegap").innerHTML =
`<div class=debug style="justify-content: right; display: flex;">
<iframe frameborder="0"
src="ditsite/mindthegap.html?
requestInitiator=${requestInitiator}&
sp=${sp}&
lang=da"
style="width: 350px; height: 100px;"></iframe>
</div>`
Ovenstående vil vise knappen i div'en #mindthegap på siden. Selve HTLM-filen skal placeres på ditsite, fx https://min-tjeneste.dk/min-side. Bemærk parametrene requestInitiator og sp: De skal sættes i JavaScript forinden.
Parameteren sp skal sættes til det SAML-entityID som tjenesten er registreret med hos WAYF. Hvis tjenesten fx er Scribo, er den korrekte værdi altså https://scribo.dk, som det fremgår af WAYFs metadataregister.
Værdien af requestInitiator skal være en URL ind i tjenesten som kan kaldes med parameteren entityID og svare browseren med: en 302 som udgør en loginforespørgsel til den institution brugeren har valgt. Sådan en URL kaldes en request initiator. Parameteren entityID skal være SAML-entityID'et i WAYF for institutionen hvis logintjeneste brugeren skal sendes hen til. Hvis dét fx er Københavns Universitet, er den korrekte værdi altså http://federation.ku.dk/adfs/services/trust, som det fremgår af WAYFs metadataregister.
For at kunne besvare kaldet af sin request initiator med en brugbar 302 må tjenesten enten understøtte en form for scoping eller i selve redirect-URL'en stile loginforespørgslen direkte til den logintjeneste som parameteren entityID angav – afhængigt af om tjenesten har metadata kun for WAYFs SSO-gateway eller særskilt for hver institution som indgår i WAYF.
En tjeneste skal implementere en request initiator for at kunne bruge WAYFs nuværende implementering af RA21-knappen. Men WAYF arbejder på en udgave af knappen som ikke forudsætter at tjenesten udstiller en request initiator.
Eksempel på dannelse af JavaScript-parametrene sp og requestInitiator forud for kaldet i boksen ovenfor:
var requestInitiator = encodeURIComponent('https://sp.example.com/saml/ri?login=1&scoping=scoping')
var sp = encodeURIComponent('https://sp.example.com/entity')