STERKE AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA SURFCONEXT Business model SuaaS Eefje van der Harst – Productmanager SURFconext

Cloud first – vraagt om hoger betrouwbaarheidsniveau

Bedenk eens wat er mis kan gaan… Fraude met cijferadministratie Lekken van patenten/ onderzoeksdata Persoonlijke gegevens van gebruikers op straat Etc., etc.

Hoe organiseer je dat als instelling? Veel integratie-effort bij instelling (n=160) Per clouddienst een nieuw token? Zoveel leveranciers, zoveel tokens. Vendor lock-in dreigt €€€ Duur, vooral bij kleine user base Uitgifteprocessen belangrijk voor betrouwbaarheid

Uitbreiding SURFconext

Inloggen nieuwe stijl 1. Iets wat je WEET + 2. Iets wat je HEBT

Wat willen we bieden: Betere toegangsbeveiliging tot clouddiensten 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

A RCHITECTUUR

W ELKE TECHNISCHE ELEMENTEN MAKEN S UAA S UNIEK ? Dienst wordt centraal as-a-service aangeboden i.p.v. on premise bij instelling SAML2.0 WebSSO protocol Ondersteuning voor meerder authenticatiemiddelen (SMS, Yubikey, TIQR), + mogelijkheid tot uitbreiding Voortbouwen op functionaliteit SURFconext (User consent, attribute release policy, opt-in, SURFconext Dashboard etc.)

Technische belemmeringen Niet alle authenticatiemiddelen van andere leveranciers kunnen ondersteund worden. Alleen geschikt voor gebruik bij webdiensten (dus geen: RADIUS, VPN-toegang, lokale systemen) Hergebruik van SuaaS-tokens voor interne applicaties binnen de instelling (nog) niet geborgd (tenzij dienst op SURFconext wordt aangesloten) Inbrengen van eigen tokens die reeds in gebruik zijn binnen instelling Incorporeren van bestaande registratieprocessen die niet conform SuaaS-policy zijn.

Token registreren

Token activeren

Pilot 1: Windesheim

Pilot 2: Deltion college + Sharepoint 2013

Leerpunten pilots Step-up authenticatie via SURFconext werkt Uitgifteproces eenvoudig op te schalen naar grotere groepen gebruikers 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, maar niet altijd nodig !Duidelijkere instructies nodig over veilig gebruik van tokens !Afhankelijkheid van SURFconext kan extra risico IdP/SP betekenen !Tariefmodel nog onduidelijk (work in progress)

T ARIEFMODEL - UITGANGSPUNTEN Kostendekkend 1-3 jaar Relatief lage instapkosten per instelling Eenvoudig op te schalen naar grotere groepen gebruikers per instelling Kosten voor instelling moeten mee stijgen naar rato van het gebruik. Intensief gebruik moet ‘beloond worden’

P LANNING ( ONDER VOORBEHOUD ) Sep 2014 – Jan 2015: Prototype ombouwen naar productiedienst, agile aanpak Tariefmodel vaststellen Documentatie, contracten, processen & procedures uitwerken Communicatie Jan 2015 Security audit => aanpassingen Feb - Mrt 2015 Bèta release + doorontwikkeling ~ Q e Productierelease + doorontwikkeling

Eefje van der Harst Vragen?

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

NB: LoA = registratieproces + middel