Introduction to Aspera authentication and authorization

Protocols

SSH authentication is the original method that is used for authentication, and is typically used for transfers between Aspera clients and servers. SSH authentication requires a system user account that is configured with a docroot or restriction in aspera.conf. The user can authenticate by providing a system password or SSH key.

HTTPS authentication, by using the Node API, supports browsing and transfers that are initiated through Aspera web applications (IBM Aspera Faspex, IBM Aspera Shares, and IBM Aspera on Cloud), and uses a token-based authorization security layer in addition to SSH.

WebSocket authentication uses token-based authorization security, and does not use SSH. You can use the Credential Manager to authenticate by running the transfer user as the system user. For more information, see Configuring Credential Manager for secure transfers that use Aspera NodeD Service (asperanoded).

Authorization tokens

When the server is configured for token authorization, the server-side ascp process requires a valid token from the client before it can start. It is the responsibility of the client to provide this token. The Aspera web applications do this process automatically through HTTPS by using the Node API. The IBM Aspera Desktop Client GUI and IBM Aspera Command Line Interface do this process automatically when it connects to Aspera web applications.

The three types of tokens that you can use are transfer tokens, basic tokens, and bearer tokens.

• A transfer token authorizes specific content uploads to a destination or content downloads from a remote source. Transfer-token-based authorization is generally used for FASP transfers that are initiated through Aspera web applications, such as IBM Aspera Faspex, and IBM Aspera Shares, but can be used in place of SSH authentication for other types of Aspera products. For more information, see Transfer token creation with the Node API and Transfer token generation (astokengen).
• A basic token is created from an access key ID and secret, which authorizes a transfer user access to a specific area of a storage and authenticates that user to the storage. Basic tokens are less restrictive than transfer tokens. They can be used to transfer with any Aspera server that supports access keys (except forIBM Aspera on Cloud). For more information, see Basic tokens.
• A bearer token is created from an access key ID, access key secret, and an SSL private-public key pair. Bearer token authentication is required for transfers to and from IBM Aspera on Cloud. Bearer tokens can optionally be used for Node user authentication and access key transfers with all other Aspera servers. For more information, see Bearer tokens.