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

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! Beveiligingsconferentie SURFcert & SURFibo 13-14 feb 2014

Wat kan er mis gaan? Een hoop…bijv: • Fraude met cijferadministratie • Lekken van patentgevoelige onderzoeksdata • Persoonlijke gegevens op straat • Etc., etc. Beveiligingsconferentie SURFcert & SURFibo 13-14 feb 2014

Veilige toegang: risico-afweging nodig • Hoe bepaal je 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 Denk aan: • • • • •

Beveiligingsconferentie SURFcert & SURFibo 13-14 feb 2014

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 Beveiligingsconferentie SURFcert & SURFibo 13-14 feb 2014

Use-cases sterke authN tot cloud apps zijn legio






Maar hoe organiseer je dat? • Zoveel leveranciers, zoveel tokens • Vendor lock-in dreigt • Tokens zijn vaak SP-afhankelijk • Implementatie bij IdP? (n=160) • Processen belangrijk voor hoogte LoA • Duur, vooral bij kleine user base

?

Architectuur: hergebruik van wat goed is

+ wat extra’s


Uitgangspunten centrale service step-up authN • Open – vendor neutraal • Kostenreductie voor IdPs • Onafhankelijk van IdP/SP implementatie • SAML-based (dus: web!)

• Centrale infra • Decentrale procedure voor uitgifte tokens & f2f vetting Beveiligingsconferentie SURFcert & SURFibo 13-14 feb 2014

Architectuur Creëer een sterkere identiteit door het koppelen van: • Bestaande instellingslogin (SAML) +

• Een tweede factor (bijv. telefoon, token)


Authenticatie flow user


NB: LoA = registratieproces + middel


Flow

-

-

1

2

3

Gebruiker: self-service registratie token

Gebruiker gaat langs bij RA, neemt mee:

RA verifieert:

(op uitnodiging) Koppelt token aan instellingslogin Levert unieke registratiecode op

-

Registratiecode Legitimatiebewijs Token

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

-

Legitimatiebewijs Of gebruiker kan inloggen met het token

Keuze middel: self-service na SAML login

Vervolgens: face-2-face vetting door RA*

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

Huidige status  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  Doel: dienstontwikkeling, toevoegen aan SURFconext Beveiligingsconferentie SURFcert & SURFibo 13-14 feb 2014

Pilots: ideeën genoeg


Doelen pilots • 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? • Hoe is user experience voor eindgebruiker & RA


Pilot: Windesheim


Eerste observaties Windesheim - Webuntis • Nu: LoA 0 = niet inloggen LoA 2 = Sterk authenticatie • Aanpassingen aan SP-applicatie nodig als je wilt differentiëren in LoAs • Moeilijk als je afhankelijk bent van leverancier • Toch weer oplossen aan IdP zijde? • Kan: maar LoA dan weer lager? Beveiligingsconferentie SURFcert & SURFibo 13-14 feb 2014

Overige observaties • Veel interesse bij instellingen in sterke authenticatie • Scope wisselt: zowel online als lokale systemen

• Niet elke use-case geschikt voor pilots (looptijd/ techniek/ test vs prod)

Disclaimer: NIET de holy grail voor alle authenticatie-issues naar lokale (beheer)systemen! Want: Step-up-authentication-as-a-service alleen voor webbased SPs


Sterke authN: nieuw kip-ei probleem?

• SP vraagt niet om hoger LoA, want IdP/ gebruiker heeft dit niet • IdP/ gebruiker levert geen hoger LoA omdat er geen SP is die er om vraagt


Driver voor hoger LoA ligt bij IdP • Hoe gaan we SPs bewegen tot het afdwingen van hogere LoAs? • Hoe kun je het voor een SP zo makkelijk mogelijk maken om LoAs te consumeren in zijn applicatie? • Kennis, ervaring, samen! Beveiligingsconferentie SURFcert & SURFibo 13-14 feb 2014

Vragen? Eefje van der Harst [email protected] www.surfnet.nl

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

Recommend Documents