Secure access to Australia's supercomputing research infrastructure

The problem

Australia’s high-performance computers (HPC) are shared research infrastructure, with researchers booking time and connecting into systems to conduct calculations and simulations. When it comes to access and security, supercomputers face challenges due to their specialised hardware, architectures, security requirements and large-scale parallel processing capabilities.

Many HPC clusters and supercomputers run on Linux-based operating systems due to their stability, performance, and open-source nature. Linux systems typically offer a powerful command-line interface (CLI), allowing users to interact with the system directly through text-based commands. This CLI is well-suited for managing and controlling HPC resources, submitting batch jobs, monitoring job status, and accessing scientific software tools.

They also use Secure Shell (SSH) Protocol which is a secure network protocol that enables encrypted communication between a client and a server over an insecure network. SSH provides strong encryption algorithms and authentication mechanisms, ensuring that data transmitted between the client and the HPC system remains confidential and secure.

Despite the advantages that CLI and the SSH connection provide, they also present several access and security challenges that inlcude:

  • Authentication: Ensuring secure authentication is crucial for SSH access to supercomputers. Password-based authentication can be vulnerable to brute-force attacks if weak passwords are used or if a users’ credentials are compromised. Implementing strong authentication methods such as public-key authentication or multi-factor authentication (MFA) can enhance security by requiring additional verification steps beyond just a password.
  • Key management: Public-key authentication relies on the management of cryptographic key pairs, consisting of a private key stored securely by the user and a corresponding public key stored on the server. Managing these keys securely, including generating them with sufficient entropy, protecting them from unauthorised access, and regularly rotating them, is essential for preventing unauthorized access and maintaining the integrity of SSH connections.
  • User access control: Supercomputers support multiple users and projects, each with different access requirements and privileges. Implementing granular access controls based on user roles, groups, and permissions ensures that users only have access to the resources and data necessary for their work. Regularly reviewing and updating access permissions helps minimise the risk of unauthorised access and data breaches.
  • Identity assurance: Identity assurance is an approach that ensures that a person’s claimed identity is their real identity. Because of the sensitivity of data and resources provided by high performance computers, they could be subject to policies (such as Defence Trade Controls Act) restricting access to these resources for certain groups of individuals. An identity assurance solution for supercomputers need to consider these requirements. Federated access can eliminate the overhead of implementing identity assurance and multifactor authentication for HPC providers.
  • Federated access: Supercomputers and HPC providers work as part of a research infrastructure network. HPC users usually, have credentials linked to a research institute or a university. Being able to provide a seamless access experience for users who are working across multiple HPCs or research facilities in a secure way is another challenge faced by HPC providers.

Currently there are multiple HPC providers across the Australian research sector. Each HPC provides different workflow and access processes, and a user needs to learn different systems, environments, and workflows to be able to use each HPC. This highlights a need for federated access across these resources.

The AAF is exploring different approaches to implementing federated access across the varied resources offered by HPC facilities, considering the challenges faced by these facilities.

The solution

Different HPC facilities have different procedures and tools when it comes to authentication and authorisation. However, as was mentioned, as they all commonly use Linux and are accessed through SSH and command line, any federated access solution for HPCs, will need to consider the following technical specifications:

  • Integration: HPCs have a complex architecture with a specialised authentication and authorisation systems in place. Integrating federated access with existing infrastructure without disrupting the operations or compromising the security requires careful planning and coordination.
  • Protocol compatibility: Ensuring the compatibility between standard authentication protocols such as SAML and OpenID Connect and SSH authentication mechanism.
  • Attribute mapping and translation: Federated identity providers may use different attribute schemas and formats to represent user identities and attributes. Mapping and translating attributes between federated identity providers and SSH authentication systems requires defining consistent attribute mappings and transformation rules to ensure that user attributes are correctly interpreted and applied for access control decisions.
  • Single Sign-On (SSO) integration: Federated access often involves implementing single sign-on (SSO) capabilities, allowing users to authenticate once with their identity provider and access multiple services without re-entering credentials. Integrating SSO with SSH authentication mechanisms requires developing custom solutions or leveraging existing SSO frameworks that support SSH authentication.


There are several solutions that could be assessed depending on the requirements of the context, addressing some of the above-mentioned requirements:

  • OIDC device Flow: Allows integration with HPCs and using federated identity through command line access. Uses open ID connect tokens, which could be consumed by SSH (see ssh-oidc). OIDC device flow allows for attribute mapping between federated identities and SSH server. However, it introduces complexities to the access workflow.
  • Certificate authority: A SSH certificate is a SSH public key with some additional information, signed by a SSH certificate authority. It can use SAML or OIDC depending on the federation technology. The certificate includes available information, validity time and potentially a schema for mapping users’ SAML identity to a unix username.
  • OAuth authorisation for SSH: OAuth SSH allows different institutions to use shared identities for secure access to the SSH platform, creating a consistent security system. It relies on OIDC tokens and introspect account mapping for authentication.

Use Case

Pawsey Supercomputing Research Centre

The AAF are working with the Pawsey Supercomputing Research Centre as an incubator to explore federated access to their HPC. As the incubator is currently in progress, this is a point in time reflection of our current understanding.

AAF is working with Pawsey to develop a solution for federated access to their resources. Pawsey provides HPC and data services to researchers in Australia and internationally. They host several super computers and cloud services which support a wide range of scientific and engineering applications.

Currently, there are several avenues for Australian researchers to apply for a Pawsey allocation. After a request for an allocation is approved, users are invited to create an account on Pawsey resource allocation platform. Users then can manage their allocation and project – as well as invite other users, manage storage keys, and update their account details.

To access a supercomputer, users have a Pawsey credentials and access supercomputers remotely through the SSH protocol. One of the main goals for the Pawsey incubator is to simplify a user’s experience and enable federated identity access to the allocation management service and the super computers.

The AAF has investigated this requirement in conjunction with existing services, and future external partnerships / integration possibilities to identify further requirements that should be considered in proposing a solution:

  • The solution should simplify user’s experience across all Pawsey services and provide a consistent user experience for all users.
  • The solution should support future external integrations with other research facilities.
  • The solution should improve the security practices and reduce cyber security risks across all Pawsey services.

Contact the AAF

If you would like to discuss trust and identity for your organisation, please contact us and one of our project managers will be in contact.

Keep up to date with all the latest news and events

Sign up to our newsletter to keep up to date with news and events.