Strong authentication via SURFconext Walter van Dijk.

Presentatie over: "Strong authentication via SURFconext Walter van Dijk."— Transcript van de presentatie:

1 Strong authentication via SURFconext Walter van Dijk

2 Cloudsourcing: new privacy & security challenges

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

4 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?

5 SURFconext: something old + something new

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

7 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

8 A RCHITECTURE

9 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

10 Token registration process: partly self-service

11 Locally at institution: bind federated ID to 2 nd factor

12 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

13 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 ~ Q2 2015 1st Production release +further development

14 Discussion

15 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 ~ Q2 2015 1 e Production release + further development

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

17 www.surfnet.nl Eefje van der Harst Eefje.vanderharst@surfnet.nl Questions?

18 Tarief Tariefmodel – flat fee 20152016 e.v. Kleine instelling < 5.000 nominaal # medewerkers + studenten Flat fee € 225 p/m € 450 p/m Grote instelling > 5.000 nominaal # medewerkers + studenten Flat fee € 550 p/m€ 1.100 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%

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

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

21 Levels of Assurance explained: process + token