Infrastruktur med möjligheter E-identitet för offentlig sektor (Efos)

Transkript

1

2 Infrastruktur med möjligheter E-identitet för offentlig sektor (Efos)

3

4 Hur passar Efos in i referensarkitekturen?

5 som hand i handske skulle jag vilja hävda

6 Helt enkelt därför att både: det gamla sättet att logga in (A) och det nya sättet att logga in (B) Är enkelt att tillämpa i referensarkitekturen

7 Det vill säga A B Här är rätta stället! Integrera inte olika autentiseringsmetoder här

8 Dubbelriktad TLS med kort Lösenord Engångskoder via SMS Mobilt BankID (privatpersoner) U2F (FIDO) Osv Osv Utan att behöva ändra minsta lilla detalj här! Lägg till ta bort eller ändra på autentiseringsmetoder här!

9 Men om vi backar lite - Vad är det gamla sättet att logga in? Gamla sättet => - Vanligtvis end-to-end uppkopplingar mellan webbläsare och webbserver med TLS-protokollet - Givetvis med stöd av PKI-infrastrukturens OSCP/CRL (låt oss sluta prata om SSL eftersom man inte får köra SSL längre)

10 det gamla sättet att logga in

11 Så vad är problemet med det gamla sättet att logga in? Svar: 1) Ingen som helst kontroll över användarupplevelsen, mycket webbläsarberoende och ibland är det så illa gjort att det utgör rena hånet mot slutanvändaren. Sämst i klassen är Apples Safari med Firefox på näst sista plats. 2) Många webbservrar är felkonfigurerade på TLS-nivå => a) Vissa användare kan helt enkelt inte logga in b) Säkerhetsrisker 3) Dubbelriktad TLS (med klientcertifikat i profilen) kan göras med Safari (ios) och Chrome (Android), men nån PIN-kod behöver inte anges (går inte att ställa in) 4) Omöjligt att separera informationskanal från säkerhetskanal

12 Microsoft: Internet Explorer på Windows 7 +

13 Microsoft: Edge och Internet Explorer på Windows 10 (med Microsofts CSP) +

14 Google: Chrome Tekniskt korrekt men 99% irrelevant för en användare +

15 Mozilla: Firefox Tekniskt korrekt men 100% irrelevant för en användare +

16 Apple: Safari 1. Dubblerar certifikaten 2. Listar irrelevanta certifikat 3. Sparar valet i KeyChain så att man mister möjligheten att välja nästa gång +

17 Matris för Net id Enterprise Linux

18 Matris för Net id Enterprise OS X

19 Matris för Net id Enterprise - Windows

20 Vilka nya tekniska lösningar införs och vad löser de för framtida krav?

21 Vilka nya tekniska lösningar införs och vad löser de för framtida krav? Det har ju hänt en del sedan SITHS-avtalet undertecknades En massa små men viktiga tekniska detaljer: - Edge påverkar både dubbelriktad TLS och signering/underskrift (Dubbelriktad TLS fungerar men kräver särskild konf, signering/underskrift fungerar inte) - Chrome fungerar inte länge för signering/underskrift - Firefox fungerar inte längre för signering/underskrift - Webbläsartillverkarna är inte längre lika slapphänta med taskigt konfigurerade webbservrar - Nya kort har kommit - Nya typer av bärare finns på marknaden Men kanske allra viktigast: - Användarna ÄR mobila och VILL VARA mobila - och det finns appar/lösningar att använda i ett mobilt arbetssätt (även om mycket återstår av både kodande och verksamhetsutvecklande)

22 Trumvirvel

23 Net id Access

24 Net id Access: - Fungerar som Mobilt BankID - Fast kostnad, inte 17 öre per inloggning - Stödjer både hårda och mjuka ID-handlingar

25 Om vi pratar om applikationer som körs via webbläsaren Enkelt: Lite redirects och GET och POST å sånt. (det här kan IT-nissarna) Logiken för att trigga igång appväxling eller att be användaren starta sin säkerhetsapp på annan enhet ligger hos autentiseringstjänsten (netid:///)

26 Men om det inte är via webbläsaren, tänk om det är en app? Vem ska då ta ansvar för appväxlingen i en lösning enligt referensarkitekturen? (Ni vet, sådär som med bankapparna som växlar till BankID och sen tillbaka )

27 Första varianten: Appen själv tar ansvaret för appväxling! Dvs, efter att a) Appen skickat en signal till applikationsservern att den vill logga in b) Applikationsservern har bett autentiseringsservern att fixa en inloggning c) Applikationsservern fått besked från autentiseringsservern att inloggning är påbörjad d) Applikationsservern informerat appen att nu är det dags att appväxla e) Appen kör: netid:///?autostarttoken= &redirect=https%3a%2f%2fservice.secmaker.com%2fref erence-applications%2fref009%2fdashboard%2findex.php

28 Andra varianten: Autentiseringstjänsten tar ansvaret för appväxling! Dvs, efter att a) Appen visar autentiseringsserverns egen grafik b) Autentiseringsservern tar hand om allt c) Autentiseringsservern kör: netid:///?autostarttoken= &redirect=https%3a%2f%2fservice.secmaker.com%2fref erence-applications%2fref009%2fdashboard%2findex.php

29

30 Vi tar det igen! Efos innebär att förutom den självklara PKI-leveransen så ingår även en ny autentiseringsmetod av typen out-of-band. SITHS och MCA => Bara elektroniska ID-handlingar med tillhörande OCSP/CRL E-identitet för offentlig sektor => Elektroniska ID-handlingar med tillhörande OCSP/CRL och en autentiseringsmetod (med signeringsstöd)

31 Matris för Net id Access

32 Nu tror ni att jag bara skojar Eller att jag vill visa på ett endast akademiskt intressant plattformsoberoende Icke så. Jag är gravallvarlig. Ni har redan idag leverantörer av medicinteknisk utrustning som kontaktat mig för att diskutera lösningar för stark autentisering i sammanhang där man svårligen kan peta in en kortläsare eller ens en liten nyckelfil med tillhörande PKIklient. Och detta för att landsting krävt stark autentisering!

33 Hur kan vi förbereda oss redan nu?

34 Hur kan vi förbereda oss redan nu? 1) Skapa en enkel och konkret strategi för autentisering 2) Säkerställ att nya applikationslösningar stödjer referensarkitekturen, dvs ställ krav vid upphandling. 3) Ta reda på hur det ser ut i den existerande applikationsfloran avseende SAML, OAuth2, OpenID osv. 4) Säkerställ att ni har förmågan att i egen hall eller som tjänst kunna lägga till, ta bort och förändra autentiseringsmetoder 5) Börja jobba!

35 Funderingar om Efos i allmänhet, priser etc. => Efos (FK / Inera) Funderingar om detaljer i produkterna som FK / Inera rimligen inte kan svara på => jonas.oholm@secmaker.com