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

En presentation över ämnet: "Anvisningstjänstens roll inom infrastrukturen för Svensk e-legitimation Martin Lindström 2012-09-06."— Presentationens avskrift:

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

2 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.

3

4 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.

5 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)

6 Val av e-legitimation

7 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.

8 Användarens förval (forts)

9 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å).

10 Användarens aktuella val (forts)

11 Hantering av tillitsnivåer

12 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

13 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

14 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.

15 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.

16 AF: ”Kontrollerad” SSO

17

18 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.

19 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

20 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!

21 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, …

22 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.

23 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)

24 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)