Federated authentication
SURF Research Access Management allows users from research and education institutions to login to research services using their institutional account. The advantages of this are that the user doesn't need to remember yet another account name with password, the service provider does not need to provide users with accounts, safely store the credentials and remove accounts when they are not needed anymore (as required by the GDPR). In addition, every login assures the user's institutional account is still valid, so the user is employed by the institution the service provider might have an agreement with. Finally, federated authentication enables two factor authentication and single sign on.
The problem with command line interfaces
Many (research) applications nowadays are web applications, used from within a web browser. Single sign on and the protocols for federated authentication (i.e. SAML2 and OpenID connect) are designed for use in web browsers. But some research services like high performance computing and large storage clusters are operated through a command line interface (CLI), often accessed by a Secure Shell (SSH). Existing solutions to integrating federated authentication with a CLI and SSH are often cluncky to use, for example because they require the user to install a custom SSH client or require complicated configuration on the user side.
To be successful, we believe a solution should not require any changes on the user side. So we developed a module that only needs to be installed on the service, or a system enabling access to the service like a jump host, but works with any user side setup that enables SSH using a public key or password login. SURF Research Access Management provides the rest of the functionality. The user can keep using their existing SSH client and configuration.
How it works
Many CLIs support PAMs (pluggable authentication modules), which means a custom PAM can be installed on the service or jumphost to bridge the gap between CLI and webbrowser.
This makes it possible to use federated authentication with SSH as:
- a second factor, in addition to an SSH key,
- a check on the validity of the user's account with their home institution (is this researcher still employed?), or
- a passwordless and SSH keyless login.
Let's take a look at how this will work from the user's perspective. First, the user logs in to the command line service at 'researchservice.institution.nl' with username 'username' from their laptop 'laptop1234'.
After validating the user's SSH key, the PAM weblogin module asks SURF Research Access Management to authenticate this user and in return receives an URL, which is shown to the user in their terminal.
The users copies the URL to their browser and authenticates with SURF Research Access Management. This ensures the user has access to the account at their home institution, and that this account is currently active.
The verification code is shown in the user's browser.
The user enters the verification code, thus linking the federated authentication in the browser to the CLI-session and access is granted.
The log in flow in a diagram
- The user connects their terminal to the service's CLI
- The PAM notifies SURF Research Access Management the user wants to authenticate
- SURF Research Access Management responds with an URL
- The URL is shown in the user's terminal
- The users copies the URL to their browser and authenticates with SURF Research Access Management
- The verification code is shown in the user's browser
- The user enters the verification code, thus linking the federated authentication in the browser to the CLI-session. Access is granted.
How to get started
Based on conversations with future users and the experiences with a proof of concept, SURF is developing a security audited production version. You can follow our progress in the repository on GitHub.
If you want to connect a CLI research service you manage as a proof of concept, of have questions or ideas, please contact us.
0 Praat mee