Anvisningstjänstens roll inom infrastrukturen för Svensk e-legitimation Martin Lindström

Syftet med en central Anvisningstjänst •Avlastar e-tjänster från att hantera alla möjliga val av Identitetsutfärdare → Minskad komplexitet för e-tjänster. •Erbjuda funktionalitet för att hantera förvalda e-legitimationer → Underlätta för användare. •Erbjuda funktionalitet för att underlätta Single Sign On inom federationen. •Lösa upp komplexitet kring tillitsnivåer.

Grundkriterier och förutsättningar •Den nya infrastrukturen ska göra det enklare och billigare för e-tjänster att erbjuda e-legitimationsanvändande → Anvisningstjänsten ska vara enkel och rättfram att integrera mot. •Val av e-legitimation ska endast exponeras för användaren då inga andra möjligheter finns → Användarvänlighet. •Ska baseras på befintliga standards och profiler.

Anvisningstjänstens uppgift •Läsa federationens metadata och sammanställa val av metod/identitetsutfärdare baserat på: •e-tjänstens begärda tillitsnivå. •Användarens egenskaper •Webbläsare, mobil enhet, OS, … •Användarens tidigare val (förval). •Användarens val i aktuell session. •(Visa federationsinformation)

Val av e-legitimation

Användarens förval •Syfte: Förenkla valprocessen för användaren. •Knutet till webbläsaren via cookie •… med lämplig livslängd. •Flera olika förval kan vara lagrade: •Val för olika tillitsnivåer. •Flera användare kan dela webbläsare.

Användarens förval (forts)

Användarens aktuella val •Syfte: Förenkla valprocessen för användaren + understödja SSO inom federationen. •Knutet till webbläsaren via sessions-cookie. •Svårt att helt eliminera inblandning av Anvisningstjänstens UI •Användaren kanske vill använda annan metod. •Användaren kanske ångrar vald metod. •Vald metod kanske inte går att använda av e-tjänsten (t.ex. vid ”fel” tillitsnivå).

Användarens aktuella val (forts)

Hantering av tillitsnivåer

AF: Användaren loggar in mot e-tjänst Användaren loggar in mot e-tjänsten Begäran om anvisning genom HTTP redirect till DS Användaren väljer e-legitimation (IdP) DS skriver cookies (session + förval) Resultat (valet) returneras till SP genom HTTP redirect DS förval DS session

HTTP redirect till angiven IdP för autentisering (AuthnRequest) Användaren autentiseras med den valda e-legitimationen IdP skriver SSO-cookie HTTP POST meddelande innehållande Response-meddelande för autentisering (Identitetsintyg) e-tjänsten kan nu logga in användaren! IdP SSO

Single Sign On Två olika typfall: 1.Användaren loggar först in mot e-tjänst X, för att sedan logga in mot e-tjänst Y. 2.Användaren loggar först in mot e-tjänst X. Inom denna e-tjänst finns möjlighet att länkas vidare till e-tjänst Y.

Sömlös inloggning mellan e- tjänster •”Kontrollerad” SSO. •Användarens val av IdP/e-legitimation återanvänds. •Kräver samverkan mellan e-tjänsterna.

AF: ”Kontrollerad” SSO

Single Sign On – Generellt fall •Användaren loggar in mot två e-tjänster inom samma session. •Anvisningstjänstens inblandning är nödvändig. •Kräver ingen samverkan mellan e-tjänster.

AF: Anvisningstjänsten och SSO Användaren loggar in mot en ny e-tjänst Begäran om anvisning genom HTTP redirect till DS DS förval DS session Användaren bekräftar tidigare val av e-legitimation (IdP) Det bekräftade valet returneras till SP genom HTTP redirect

IdP SSO HTTP redirect till angiven IdP för autentisering (AuthnRequest) HTTP POST meddelande innehållande Response-meddelande för autentisering (Identitetsintyg) e-tjänsten kan nu logga in användaren! Single Sign On!

Ytterligare diskussioner … •Måste en e-tjänst styra användarna till den centrala Anvisningstjänsten? •Vi vill ha vår egen look’n’feel! •Vi har en mix av egna autentiseringsmetoder och e-leg. Hur gör användarna val då? •Hur hanteras tillitsnivåer? •Central tjänst → Nytta kan dras … •Visa statusinfo för federationen. •Hjälpsidor, info om e-legitimationer, …

Möjliga variationer av Discovery •Central tjänst med federationsspecifikt UI.  Enkel integration för e-tjänsten.  Medger stöd för sparade val och SSO-stöd.  Möjligt att visa federationsinfo (status, mm)  SPOF!  Annat utseende än e-tjänsten (Är detta ett minus?) •Central tjänst med JSON-feed (via Cross domain AJAX).  Förhållandevist enkelt att integrera.  Medger stöd för sparade val och SSO-stöd.  Bibehåller e-tjänstens look’n’feel.

Möjliga variationer av Discovery (2)  SPOF!  Cross Domain AJAX! Hmm … •Lokal DS – SP läser metadata och gör allt på egen hand.  Full kontroll för e-tjänsten.  Ingen SPOF för federationen.  Komplex implementation för e-tjänsten.  Förval och SSO-stöd för federationen försvinner.  Kräver kontroll av e-legitimationsnämnden? (Alla IdP:er måste visas korrekt)

Möjliga variationer av Discovery (3) •Lokal DS med nyttjande av central ”cookie- tjänst”.  Full kontroll för e-tjänsten.  Ingen SPOF för federationen.  Medger stöd för sparade val och SSO-stöd.  Ännu mer komplex implementation för e-tjänsten!  Kräver kontroll av e-legitimationsnämnden? (Alla IdP:er måste visas korrekt)