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 gebruikersop 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
ARCHITECTUUR
WELKE TECHNISCHE ELEMENTEN MAKEN SUAAS 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, lokalesystemen)
•Hergebruik van SuaaS-tokens voor interne applicaties binnen de instelling (nog) nietgeborgd (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)
TARIEFMODEL - 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’
PLANNING (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
•1e Productierelease + doorontwikkeling
www.surfnet.nl
Eefje van der Harst
Eefje.vanderharst@surfnet.nl
Vragen?
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
NB: LoA = registratieproces + middel
