Strong authentication via SURFconext Walter van Dijk

Cloudsourcing: new privacy & security challenges

Imagine what can go wrong… Fraud with exam results Research data leaks Privacy data breaches Etc., etc.

Strong authentication? YES please! But how? High integration effort for institution (n=160) So many vendors, so many tokens. Vendor lock-in? €€€: expensive, especially for small user base Issuance process: prerequisite for ID-Assurance Levels User: Every cloud service a new token?

SURFconext: something old + something new

Authentiction via SURFconext ‘2.0’ 1. Something you KNOW + 2. Something you HAVE

Value proposition Improve access security for cloud services Minimize risks of security incidents Easy rollout (technical + process) Competitive pricing model Ease of use for end user: unified access with 1 second factor for multiple applications

A RCHITECTURE

Strong authentication via SURFconext: limitations Initially only support for SMS, Tiqr, Yubikey Web only (no: RADIUS, VPN, local systems) Re-use of SMS, Tiqr and Yubikey tokens for internal applications (unless connected to SURFconext) Re-use of other tokens that are already being used at institution Other enrollment processes not conform SURFconext-policy

Token registration process: partly self-service

Locally at institution: bind federated ID to 2 nd factor

Lessons learned pilots Strong authentication via SURFconext works! Enrollment process is easy to scale up Service Provider can handle user ID’s with different Levels of Assurance ±‘Startup problems’ no different from IdP-central strong authentication solutions ±Difficult for applications to differentiate in Levels of Assurance (but not always necessary) !Users need clear instructions on proper use of authentication tokens !Pricing model: to be determined

P LANNING ( SUBJECT TO CHANGE ) Sep 2014 – Jan 2015: Develop production ready service, agile approach Determine pricing model Develop documentation, contracts, processes etc. Communication Jan 2015 Security audit + further development Feb - Mrt 2015 Bèta release + further development ~ Q st Production release +further development

Discussion

Planning Sep 2014 – Jan 2015: Communication From prototype towards production service, agile approach Tariffmodel Documentation, contracts, processes & procedures Jan 2015 Security audit => implement recommendations Feb - Mrt 2015 Bèta release + further development ~ Q e Production release + further development

Discussion Strong authentication will become the authentication standard for HE&R: the end of username/password

Eefje van der Harst Questions?

Tarief Tariefmodel – flat fee e.v. Kleine instelling < nominaal # medewerkers + studenten Flat fee € 225 p/m € 450 p/m Grote instelling > nominaal # medewerkers + studenten Flat fee € 550 p/m€ p/m NB: -Tarieven exclusief eventuele kosten van tokens (sms transacties, Yubikey) -Minimale afnameduur 3 jaar -Gebruikers = aantal medewerkers + studenten dat verbonden is aan de instelling, ongeacht of zij gebruik maken van de dienst -Vooralsnog maakt de dienst geen onderdeel uit van het kernpakket -In 2015 geldt een introductiekorting van 50%

Uitgangspunten tariefmodel Kostendekkend 1-3 jaar Relatief lage instapkosten per instelling Eenvoudig op te schalen naar grotere groepen gebruikers per instelling Intensief gebruik door instellingen moet ‘beloond worden’

Bron: ISO Levels of Assurance explained LoADescription 1 - Low Little or no confidence in the claimed or asserted identity 2 - Medium Some confidence in the claimed or asserted identity 3 - High High confidence in the claimed or asserted identity 4 – Very high Very high confidence in the claimed or asserted identity

Levels of Assurance explained: process + token