What s

Transcriptie

1 What s STEP-UP AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA SURFCONEXT Eefje van der Harst - Productmanager

2 Waarschuwing vooraf: jargon alert (sorry) Level of Assurance (LoA) Registration Authority (RA) Identity Vetting

3 Hoger onderwijs & onderzoek: cloud is the way Steeds meer applicaties in de cloud Anytime, anywhere, any device toegang is het credo Laagdrempelig toegang voor gebruikers; JA! MAAR: dan wel veilig!

4 Wat kan er mis gaan? Fraude met cijferadministratie Lekken van patentgevoelige onderzoeksdata Persoonlijke gegevens op straat Etc., etc.

5 Use cases voor sterke authenticatie zijn legio

6 Veilige toegang: risico-afweging nodig Hoe bepaal je vereiste betrouwbaarheidsniveau? Wat is juiste risico-inschatting? Wat is gewenste beschermingsniveau? Volg internationale standaarden: ISO NIST STORK

7 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

8 NB: LoA = registratieproces + middel

9 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

10 Architectuur: hergebruik van wat goed is

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

12 Architectuur

13 Wat willen we bieden: Hogere betrouwbaarheid van de identificatie en authenticatie van de gebruiker (LoA 2 en LoA 3 volgens ISO29115) Betere toegangsbeveiliging tot SURFconext SPs (dus: webbased!) Beperken van risico s op beveiligingsincidenten Eenvoudige uitrol (techniek + proces) Concurrerend tariefmodel Gemak voor de eindgebruiker: uniforme toegang met één tweede factor voor meerdere diensten

14 Wat maakt de dienst bijzonder Centrale infra as-as-service ; geen aanpassingen aan IdP nodig SAML based (dus: alleen geschikt voor web) Sterke koppeling tussen federatieve identiteit en tweede factor LoAs compatible met internationale standaarden (NIST, STORK, ISO29115) Voor Service Providers maakt het niet uit welke van de ondersteunde tokens instellingen/ gebruikers kiezen Kostenreductie instellingen

15 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 Business model + business case uitwerken ism instellingen Pilots succesvol? Dan: dienstontwikkeling, toevoegen aan SURFconext

16 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? (= alleen op relevante plekken in applicatie vragen om ander LoA?) Hoe organiseren we uitgifteproces tokens? Hoe is user experience voor eindgebruiker & RA

17 Pilot 1: Windesheim

18 Observaties Windesheim SP-koppeling Webuntis Nu: LoA 0 = niet inloggen LoA 2 = Sterk authenticatie - Verregaande aanpassingen aan SP-applicatie nodig als je wilt differentiëren in LoAs - Moeilijk als je afhankelijk bent van leverancier* *) 80% van het werk is standaard SAML-koppeling SURFconext

19 Ervaringen Service Desk mbt registratieproces Werkt prima, proces reeds bekend van uitgifte andere middelen Check legitimatie wordt over algemeen serieus genomen Registratieproces eenvoudig op te schalen naar grotere groepen gebruikers

20 Ervaringen eindgebruikers Registratieproces werkt prima Gebruikers waarderen keuzevrijheid in token (SMS/ Yubikey) User experience bij switch tussen applicaties met hoger/ lager LoA in orde Telefoon laat een gebruiker niet gauw slingeren! Yubikey in gedrag nu soms nog onveilig; laat je gemakkelijk in USBpoort zitten => instructies verbeteren!

21 Overige leerpunten 1e pilot Step-up authenticatie via SURFconext werkt SP kan goed omgaan met verschillende LoAs ± Evt. Opstartproblemen zouden ook bestaan als IdP zelf 2FA zou implementeren! Differentiëren in LoA nog lastig voor SP! Duidelijkere instructies nodig over veilig gebruik van tokens! Afhankelijkheid van SURFconext kan extra risico IdP/SP betekenen! Tariefmodel nog onduidelijk (work in progress)

22 Pilot 2: Deltion college + Sharepoint 2013

23 Pilot 3: Hanze hogeschool & Osiris (ovb)

24 Use cases voor sterke authenticatie zijn legio

25 Overige observaties nav gesprekken instellingen 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: Dit wordt NIET de holy grail voor alle authenticatie-issues naar lokale (beheer)systemen! Want: Step-up-authentication-as-a-service alleen voor webbased SPs

26 Sterke authn: nieuw kip-ei probleem? SP vraagt niet om hoger LoA, want IdP/ gebruiker heeft dit niet (MAAR: kan het wel als USP richting IdP gebruiken) IdP/ gebruiker levert geen hoger LoA omdat er geen SP is die er om vraagt

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

28 Vragen? Eefje van der Harst

29 SURFconext bijeenkomst op maat Informatie op maat over SURFconext. De behoefte van de instelling staat voorop en in overleg worden de onderwerpen bepaald. Voorbeelden: Diensten afnemen, juridisch, aansluiten eigen diensten, gebruik groepen, portals, (internationaal) samenwerken via SURFconext Voorwaarden: - Intake-gesprek - SURFconextverantwoordelijke en contactpersoon software en/of content zijn aanwezig bij de sessie: dit zijn key users van SURFconext Meer info/aanmelden voor 1 juli 2014 via sabita.behari@surfnet.nl

30