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

Presentatie over: "STERKE AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA SURFCONEXT Business model SuaaS Eefje van der Harst – Productmanager SURFconext."— Transcript van de presentatie:

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

2 Cloud first – vraagt om hoger betrouwbaarheidsniveau

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

4 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

5 Uitbreiding SURFconext

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

7 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

8 A RCHITECTUUR

9 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.)

10 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.

11 Token registreren

12 Token activeren

13 Pilot 1: Windesheim

14 Pilot 2: Deltion college + Sharepoint 2013

15 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)

16 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’

17 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 ~ Q2 2015 1 e Productierelease + doorontwikkeling

18 www.surfnet.nl Eefje van der Harst Eefje.vanderharst@surfnet.nl Vragen?

19 Bron: ISO 29115 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

20 NB: LoA = registratieproces + middel