Multi-factor authenticatie voor cloudapplicaties via surfconext Samen veilig online Multi-factor authenticatie voor cloudapplicaties via surfconext Eefje van der Harst - Productmanager

Hoger onderwijs & onderzoek: cloud is the way Steeds meer applicaties in de cloud Anytime, anywhere, any device toegang is het credo De klant* is koning! Of niet? *) student/ medewerker/ onderzoeker Laagdrempelig toegang voor gebruikers; JA! MAAR: dan wel veilig!

Wat kan er mis gaan? Een hoop…bijv: Fraude met cijferadministratie Lekken van patentgevoelige onderzoeksdata Persoonlijke gegevens op straat Etc., etc.

Veilige toegang: risico-afweging nodig door IdP Hoe bepaalt instelling het vereiste betrouwbaarheidsniveau? Wat is juiste risico-inschatting? Wat is gewenste beschermingsniveau? Volg internationale standaarden: ISO 29115 NIST 800-63 STORK http://www.surf.nl/kennis-en-innovatie/kennisbank/2014/rapport-handreiking-betrouwbaarheidsniveaus.html

Betrouwbaarheidsniveaus - Levels of Assurance LoA Beschrijving 1 - Laag Weinig of geen vertrouwen in geclaimde over verzekerd (“asserted”) identiteit 2 - Medium Enig vertrouwen in de geclaimde of verzekerde identiteit 3 - Hoog Veel vertrouwen in de geclaimde of verzekerde identiteit 4 - Zeer hoog Zeer veel vertrouwen in de geclaimde of verzekerde identiteit Bron: ISO 29115

Bepalende factor: mate van vertrouwelijkheid data Denk aan: Toetsmateriaal Toetsresultaat Studievoortgang Persoonsgegevens Onderzoeksgegevens

Bepalende factor: integriteit data Denk aan: Waardedocument (bijv. diploma) Deelnameregistratie (leeractiviteit/ statgeplaats) Onderzoeksgegeves Publicatie

Andere factoren van invloed (+/-) - - Bevestiging via andere weg Inzage in laatste inlog Herstel schade is makkelijk + + Motief voor fraude BN’ers Schaal mogelijke fraude is groot

Use-cases sterke authN tot cloud apps zijn legio Diverse cloud applicaties, denk aan storage, doc sharing

Use-cases sterke authN tot cloud apps zijn legio E-HRM applicaties

Use-cases sterke authN tot cloud apps zijn legio Rooster applicaties, cijferadministratie

Maar hoe organiseer je dat? Instelling Zoveel leveranciers, zoveel tokens Vendor lock-in dreigt Tokens zijn vaak SP-afhankelijk (dus: grote sleutelbos tokens?) Implementatie bij IdP complex & duur? (n=160) Processen belangrijk voor hoogte LoA Duur, vooral bij kleine user base Leverancier Authenticatie & token-uitgifte geen core business Oneigenlijk gebruik vqn je applicatie terugdringen USP richting instellingen 1x implementeren voor alle instellingen ipv 1:1 oplossingen per instelling

Architectuur: hergebruik van wat goed is

+ wat extra’s

Uitgangspunten centrale service step-up authN Open – vendor neutraal Onafhankelijk van IdP/SP implementatie SAML-based (dus: web!) Centrale infra Kostenreductie voor IdPs Decentrale procedure voor uitgifte tokens & f2f vetting bij IdP (scheelt werk voor SP)

Architectuur Creëer een sterkere identiteit door het koppelen van: Bestaande instellingslogin (SAML) + Een tweede factor (bijv. telefoon, token)

Authenticatie flow user

Huidige status dienstontwikkeling Prototype self-service portal registratie tokens Prototype RA-management voor identity vetting user + koppelen token Beschikbare tokens in prototype: sms en yubikey Op basis van prototype uitvoeren pilots met instellingen & leveranciers Doel: dienstontwikkeling, toevoegen aan SURFconext

Doelen pilots ism leveranciers & instellingen Wat is nodig om een SP step-up-authentication aware te maken? (time, effort, technical, knowledge) Hoe kan een SP differentiëren tussen verschillende LoAs? Hoe organiseren we uitgifteproces tokens binnen een instelling? Hoe is user experience voor eindgebruiker & Service Desk (RA)

Vragen? Eefje van der Harst Eefje.vanderharst@surfnet.nl

Achtergrond: proces uitgifte tokens 1 Gebruiker: self-service registratie token (op uitnodiging) Koppelt token aan instellingslogin Levert unieke registratiecode op 2 Gebruiker gaat langs bij Service Desk*, neemt mee: Registratiecode Legitimatiebewijs Token 3 Service Desk verifieert: Legitimatiebewijs Of gebruiker kan inloggen met het token *) Kan ook ander loket zijn in rol “registration authority”, bijv. bij IT helpdesk, HR-afdeling

Keuze middel: self-service na SAML login

Vervolgens: face-2-face vetting door RA* *) RA = registration authority, bijv. bij IT helpdesk, service desk, HR