Transfer Authorization is the process in which the Aspera Server allows or denies a user from performing a transfer.  In the normal workflow the user's identity is established by this point, either with a username and password or a key.  Aspera technologies support two types of authorization; token based authorization and external authorization.

Token Based Authorization

 In Aspera Systems, Authorization tokens can be seen as non-sensitive credentials which are valid for a limited duration and hold authorization information for uploading or download files. The token is in the form of an encrypted, non-human readable text string which contains information about the files, user, type of transfer, and lifetime.  The data is encrypted using a key which is configured on the Aspera Server.  

tokenAuthTranferHandshake

Typically, a client who would like to transfer content would request a token from the Aspera Node.  However, there is a token generator executable available which can produce transfer authorization tokens.  The client would then pass the token along with the transfer order to the Aspera Server.  If the Aspera Server is configured for token based authorization it validates the token before authorizing the request.  If the token is valid the request is processed, if the token is invalid the request is denied.  Depending on your application needs you can easily pass the token with the transfer request, examples for different platforms are below:

Java FASP Manager SDK

XferParams p = new XferParams();p.token = "ATM2_ACsG1MjzWpgXoNcY-zkenK3iVAdNQc_1v_wZl5kPaIADHcAAHleH49YLk1pDFooM2QtYDK_2MTA";

.NET (C#) FASP Manager SDK

XferParams p = new XferParams();

C++ FASP Manager SDK

 

JavaScript Connect API

 

SOAP Job Submission API

 

CORS Support With Token Authorized Transfers

Normally custom applications requiring token authorization can make HTTP calls directly to the Node API. However, in web-based applications the web browser will normally prevent HTTP requests for these types of operations (AJAX calls).  To get around this security measure on web browsers the server needs to have CORS support.  There are a few different approaches to enable support of CORS so that a token can be generated using the Node API.  The main options include configuring your web server to act as a reverse proxy; which will make the browser think they are served from the same domain, the other method would be to implement a web service with CORS support which will act as a tunnel for the Node API; this requires you to write a simple server application to handle the requests that are received from the web browser, and should be hosted on the same server that is hosting the web files.

External Authorization

By using External Authorization businesses and application developers can use their own authorization logic by implementing their own authorization server.  To make this easier, the Aspera Server is configured to call an URL when a transfer is started and continue with the transfer based on the response from that URL.

External authorization is used to authorize transfers at session level, and should not be used in the purpose to authorize every single transfer file/directory path in the transfer session: transfer paths detail is not available in the API payload (actually, only a few of the paths are passed in the Operation/Source and Operation/Destination fields). The authorization service should be implemented to return fast.

The 'external authorization' method is deprecated. It is still supported in the product but it is an older security system and no longer advised. It is recommended to consider token-based authorization or inline validation instead.

ExternalAuth

To use External Authorization you need to configure your Aspera Server.  You will need to edit the aspera.conf file, which is located in the Aspera Server installation location.  You can configure the server to require a valid token for different cases as needed for your workflow.  An example of a the aspera.conf file's section on authorization is seen below:

 

Once you have the Aspera Server configured you need to implement an external authorizer.  This authorizer is expected to follow the contract defined in the AuthorizationNetService.wsdl file which is located on every Aspera Server at {server address}/console/services/soap/AuthorizationNETService.wsdl.  The external authorization server needs to implement a Web Service, like SOAP, to accept a request of "Authorize". The request will contain all the information available about the transfer as well as specific data to the application.  A normal SOAP request and response is seen below.  The response must contain either YES or TRUE in the Result tag if the transfer is to be allowed.

 
 

For demonstrations here is a Java implementation of an external authorizer following the WSDL contract. This example should help you in implementing your External Authorizer.

 

For demonstrations here is a WSDL file that the External Authorizer should use.

 
Video player

Video

×