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

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.

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 DS förval Begäran om anvisning genom HTTP redirect till DS Användaren väljer e-legitimation (IdP) DS skriver cookies (session + förval) DS session Resultat (valet) returneras till SP genom HTTP redirect

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

14. Single Sign On • Två olika typfall: • Användaren loggar först in mot e-tjänst X, för att sedan logga in mot e-tjänst Y. • 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

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 DS förval Begäran om anvisning genom HTTP redirect till DS DS session Användaren bekräftar tidigare val av e-legitimation (IdP) Det bekräftade valet returneras till SP genom HTTP redirect

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

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)