De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

MULTI-FACTOR AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA SURFCONEXT Samen veilig online Eefje van der Harst - Productmanager.

Verwante presentaties


Presentatie over: "MULTI-FACTOR AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA SURFCONEXT Samen veilig online Eefje van der Harst - Productmanager."— Transcript van de presentatie:

1 MULTI-FACTOR AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA SURFCONEXT Samen veilig online 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 • NIST • STORK

5 Bron: ISO Betrouwbaarheidsniveaus - Levels of Assurance LoABeschrijving 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

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

10

11

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 Eefje van der Harst Vragen?

21 Achtergrond: proces uitgifte tokens 1 Gebruiker: self-service registratie token -(op uitnodiging) -Koppelt token aan instellingslogin -Levert unieke registratiecode op 3 Service Desk verifieert: -Legitimatiebewijs -Of gebruiker kan inloggen met het token 2 Gebruiker gaat langs bij Service Desk*, neemt mee: -Registratiecode -Legitimatiebewijs -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 *) RA = registration authority, bijv. bij IT helpdesk, service desk, HR Vervolgens: face-2-face vetting door RA*


Download ppt "MULTI-FACTOR AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA SURFCONEXT Samen veilig online Eefje van der Harst - Productmanager."

Verwante presentaties


Ads door Google