Multi-factor authenticatie voor cloudapplicaties via surfconext

Presentatie over: "Multi-factor authenticatie voor cloudapplicaties via surfconext"— Transcript van de presentatie:

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

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

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

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

5 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

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

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

8 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

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

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

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

12 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

13 Architectuur: hergebruik van wat goed is

14 + wat extra’s

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

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

17 Authenticatie flow user

18 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

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

20 Vragen? Eefje van der Harst

21 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

22 Keuze middel: self-service na SAML login

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