Federated authentication for non-web-based research services

Some research services offer a command line interface (CLI), like SSH or iRODS. Techniques such as SAML and OIDC, which are used for federated authentication through a web browser, are ill-suited for use on a CLI. For SURF Research Access Management, SURF has developed a solution: a pluggable authentication module (PAM) for CLI services which allows them to use two factor federated authentication and single sign-on.

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'.

Terminal with ssh command to log into the research service

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.

Terminal showing the SURF Research Access Management challenge URL and verification code prompt

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.

SURF Research Access Management webpage with verification code

The user enters the verification code, thus linking the federated authentication in the browser to the CLI-session and access is granted.

Terminal showing user is logged in

The log in flow in a diagram

  1. The user connects their terminal to the service's CLI
  2. The PAM notifies SURF Research Access Management the user wants to authenticate
  3. SURF Research Access Management responds with an URL
  4. The URL is shown in the user's terminal
  5. The users copies the URL to their browser and authenticates with SURF Research Access Management
  6. The verification code is shown in the user's browser
  7. The user enters the verification code, thus linking the federated authentication in the browser to the CLI-session. Access is granted.
Login flow diagram

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.

Auteur

Reacties

Dit artikel heeft 0 reacties

Gerelateerde artikelen