MULTI-FACTOR AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA SURFCONEXT

Samen veilig online

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• STORKhttp://www.surf.nl/kennis-en-innovatie/kennisbank/2014/rapport-handreiking-betrouwbaarheidsniveaus.html

Bron: ISO 29115

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

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

Use-cases sterke authN tot cloud apps zijn legio

Use-cases sterke authN tot cloud apps zijn legio

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)

www.surfnet.nl

Eefje van der HarstEefje.vanderharst@surfnet.nl

Vragen?

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

Keuze middel: self-service na SAML login

*) RA = registration authority, bijv. bij IT helpdesk, service desk, HR

Vervolgens: face-2-face vetting door RA*