On SURFsara compute and storage facilities we will move away from the traditional username + password combination for authentication, in favour of stronger procedures such as certificate-based identities and two-factor authentication (2FA). 2FA ( or MFA ) in itself is a stronger mode of authentication, since, in addition to your password, you need to have something else - a ‘second factor’ - to prove your identity. The second factor, that you need to demonstrate possession of in a 2FA protocol, is commonly called a ‘token’. Not all 2FA protocols are equally strong though. The strength of a particular 2FA protocol depends in large part on the ease with which the token can be obtained, copied, reproduced, as this has direct impact on the comparative easy with which a token can be stolen.
LISA and Cartesius are the first SURFsara facility at which we support a 2FA procedure for end-users. For now, the usage of 2FA for end-users is still optional. To be more precise: as the principal investigator of a project is considered the owner of the projects and its data, only principal investigators can request 2FA. To do so, they must contact the SURFsara helpdesk.
Note:
If a principal investigator requests 2FA for his or her project, 2FA becomes mandatory for ALL logins that are associated with the project and have access to the project’s data.
In particular, individual users cannot send in tickets to be exempted from, or to undo, 2FA for their login. Neither will a request from principal investigators be honoured that requests 2FA for some but not for other logins associated with a project.
It is likely that 2FA on SURFsara facilities will become mandatory for end-users in the near future.
Enforcing logins to use 2FA to access LISA or Cartesius is a configuration operation that is separate and logically distinct from the operation of associating a login with a particular 2FA token. The latter is basically a self-service operation that is explained and documented below. To make the transition to 2FA as smooth as possible, it is best that users first obtain a token and familiarize themselves with the client application to use the token. When 2FA is enforced on a set of logins while some of the users have no valid token yet, or do not understand how to use it, those users are effectively locked out until they are able to use their token.
The first 2FA procedure currently supported on LISA and Cartesius is based on software tokens that use the Time-based One-Time Password algorithm (TOTP) to generate a 6-digit code. TOTP is a well understood and well-documented protocol (see: RFC6238, and also Wikipedia). It uses the current time as an input to generate a value that is unique and that is valid only for a very limited span of time after being generated (about 30 seconds). At each login you demonstrate proof of possession of the particular token that has been associated with your login name by responding with the 6-digit code that token the has generated for the current time interval.
A TOTP token is a so-called software token. To possess a TOTP software token you need a TOTP compliant client application that can be installed and run on the operating system platform(s) of your preference, in which you can safely store a token identity that was created for you by a TOTP server.
The following list provides a number of locations where TOTP client applications can be downloaded. More client applications exist, there are quite a few to choose from. In principle any TOTP client should work well, but the list below only contains the clients that have been tested by SURFsara (October 2019), and verified to work well. There is at least one SURFsara tested client for each of the following platforms: IOS, Android, MacOS, Linux, and Windows.
TOTP clients for IOS
TOTP client for Android
TOTP client for MacOS
TOTP client for Linux
TOTP clients for Windows
Tip:
Make sure you have at least one TOTP client installed and ready to be used on your phone or computer. Once a token identity is generated and presented to you (see below), it is associated with the loginname with which you entered the 2FA portal. You are expected to safely store and subsequently use it. You will no longer be able to login to the 2FA portal on the basis of username + password only.
To create a usable software token you must obtain a token identity associated with your login from our 2FA portal, and safely store the identifier in the TOTP compliant app of your choice. This section explains in a few illustrated steps how to do just that.
WinAuth is an example of a TOTP client app for windows computers. Instead of scanning the QR code image, you must use the Base32 code, shown in Figure 3, and enter it as the ‘Secret Code for your authenticator’ in the WinAuth dialogue shown in Figure 4. Make sure that the app knowns the codes are generated time-based rather than counter-based.
Figure 4: Winauth
Not that your token identity, in all its possible representations – QR code image, QR code image URL, Base32 string – is a shared secret between you and the TOTP server. So be ware not expose such representations of your active, valid tokens. A malevolent person who steals your shared secret can generate new, valid TOTP values at will. Precisely because of 2FA this need not be fatal: in order to pose as you take on your identity, your password is needed in conjunction with the valid TOTP value. However, when your token is compromised, you should create a new one at the portal and delete the old one - see: ‘2FA.surfsara.nl revisited: managing your token(s)’.
If you have completely lost possession of your token, you will not be able to do so and must contact SURFsara for assistance.
When you login to the portal with a login that has on or more associated tokens will find an overview of your token(s) under the ‘Tokens’ tab, similar to the overview shown in Figure 5.
Figure 5: Token overview
By clicking on the underlined token name in the left column, you can access a more detailed view shown in Figure 6. In the top right corner of the token details overview, you see a red button that can be used to delete the token. You must delete a token that is in whatever way was compromised and enroll a new token and store its identifier in you app(s).
Note that there is also an audit tab, which gives you access to the log token activity.
Figure 6: Token details
The SURFsara Data Archive allows the user to safely archive up to petabytes of valuable research data.
Persistent identifiers (PIDs) ensure the findability of your data. SURFsara offers a PID provisioning service in cooperation with the European Persistent Identifier Consortium (EPIC).
B2SAFE is a robust, secure and accessible data management service. It allows common repositories to reliably implement data management policies, even in multiple administrative domains.
The grid is a transnational distributed infrastructure of compute clusters and storage systems. SURFsara is active as partner in various...
Spider is a dynamic, flexible, and customizable platform locally hosted at SURF. Optimized for collaboration, it is supported by an ecosystem of tools to allow for data-intensive projects that you can start up quickly and easily.
The Data Ingest Service is a service provided by SURFsara for users that want to upload a large amount of data to SURFsara and who not have the sufficient amount...
The Collaboratorium is a visualization and presentation space for science and industry. The facility is of great use for researchers that are faced with...
Data visualization can play an important role in research, specifically in data analysis to complement other analysis methods, such as statistical analysis.