Aspera

Hey! I hope someone can help me. We're trying to implement a client-server authentication using a bearer token, but we're unsure what parameters to put below. We currently have an HSTS version 4 setup. We are using the Transfer SDK with a running daemon to download files. 

Where do we get the actual user_id, scope and group ids? Our Aspera server network person is also new to managing Aspera, so every detail really counts.  We're only given the  Access and Secret key as credential. 

Create a JSON file containing the bearer token payload and save it as bearer_token.json. 

{
  "user_id": "luke@aspera.us",
  "scope": "node.diDeuFLcpG9IYdsvxj0SCq4mOohNJTKvp5Q2nRWjDgIA:all",
  "expires_at": ""
  "group_ids": [],
}

Hi Angela,

The documentation link is for an older version (3.7.3) so it's not as clear as it could be. That said, the latest admin guide for HSTS 4.4.4 does not contain a similar step by step process. There is work in progress to create a similar document that is up to date and hopefully clearer.

The scope would be a string like 'node.<acess_key_id>:user:all'. In this example the access key id is 'diDeuFLcpG9IYdsvxj0SCq4mOohNJTKvp5Q2nRWjDgIA', so the scope would be 'node.diDeuFLcpG9IYdsvxj0SCq4mOohNJTKvp5Q2nRWjDgIA:user:all'. It is also possible to create a bearer token for an admin role (...:admin:all), but for transfers a user role is sufficient.

The expiration would be a timestamp in the future when you'd want the bearer token to become invalid. For example:

"expires_at": "2024-09-07T06:37:53Z"

The user_id, or group_ids, are identifiers that are mapped to permissions. This is shown in step 10 in the documentation link from your post:

10. Create permissions for user ID (access ID) luke@aspera.us to the top level of the storage.

$ curl -d '{"file_id":"1", "access_type":"user","access_id":"luke@aspera.us","access_level":"edit"}' \ -ki -u diDeuFLcpG9IYdsvxj0SCq4mOohNJTKvp5Q2nRWjDgIA:aspera https://localhost:9092/permissions

When creating a permission, it is possible to specify a user ID or a group ID (https://developer.ibm.com/apis/catalog/aspera--aspera-node-api/api/API--aspera--ibm-aspera-node-api#post960739960). To HSTS, these IDs are arbitrary identifiers but allow the setup of different permissions for different identifiers. That way the entity creating the bearer token has the capability of issuing different bearer tokens with different permissions, even if all these bearer tokens are associated with the same Access Key. 

For example, if there was a web application that provided a frontend for Aspera transfers and where different users could login, this web application could register different permissions for its different users in HSTS, and issue different bearer tokens to each specific user. Then trying to use that bearer token for a transfer, HSTS would enforce the permissions previously set for that user ID.

Regards,

Jose

{  "user_id": "luke@aspera.us",  "scope": "node.diDeuFLcpG9IYdsvxj0SCq4mOohNJTKvp5Q2nRWjDgIA:all",  "expires_at": ""  "group_ids": [],}