|
iOS SDK
3.5.0.104555
|
|
iOS SDK
3.5.0.104555
|
The Aspera Mobile SDK supports several methods of account authentication as well as an additional transfer authentication mechanism (via tokens).
Account authentication is required in order to establish a connection with the remote server, that is to say it is a mandatory process carried out at the very beginning of any FASP transfer - if it fails, the transfer fails. Supported methods include password authentication and public-key authentication.
Token authentication is an additional (optional) transfer authentication mechanism. It is usually leveraged to implement a virtual user base on top of regular transfer accounts (which are system accounts), and can in general be used to exercise finer control on a per-transfer basis. Tokens are verified by the server only after account authentication has succeeded, so tokens come into play at a later stage of the transfer process.
Together these mechanisms provide a flexible platform for deciding which transfers to authorize. The basic uses of each are described below.
Each ASAccount instance describes a remote server, including the address, communication ports and access credentials. These access credentials can take one of two forms: a username and a password, or a username and a private key. The username corresponds to a system account on the remote server, and the type of authentication to be used depends on how that system account is configured on the server. Both authentication mechanisms require setting the user attribute on the ASAccount instance.
In order to use password authentication set the password attribute on an ASAccount instance and avoid setting the privateKeyFilename attribute (one often sets the password attribute when creating the ASAccount instance, for instance using the method accountWithHost:user:password:sshPort:udpPort: (ASAccount)). The following sample code creates an ASAccount instance configured for password authentication against a server at the address "example.com" for the user "usr1" with password "testpw":
In order to use key authentication, set a blank password attribute on an ASAccount instance and set the privateKeyFilename attribute to a relative path pointing to the private key to be used (keys should be in the OpenSSH/OpenSSL format). Finally set the keyPassphrase attribute to the key passphrase for the private key (use a blank string if no passphrase is used). You will need to include the private key in your application bundle. The following sample code creates an ASAccount instance configured for key authentication against a server at the address "example.com" for the user "usr1" using the private key "my_private_key.openssh", the public key "my_public_key.pub" and a blank passhrase:
Token authentication provides an additional transfer-specific authentication mechanism for FASP transfers. A server system account that is configured to require tokens will only allow transfers that contain a valid transfer token (see ASFaspSession::token). A common use case is to have one dedicated system account over which all transfers occur and to use tokens as the ultimate factor in determining which transfers to allow. In particular, tokens may be provided by the server based on external factors, for instance an external authentication process carried out via REST APIs that is part of a virtual user model. It is the embedding application's responsibility to obtain a transfer token for each session. If an attempt is made to transfer using a system account that requires token authentication but no token is set in the tranfser session then the transfer will fail.
In its simplest form all that is necessary in order to use token authentication for a given session is to set a token on an ASFaspSession object (see ASFaspSession::token). Once a token is set on an ASFaspSession instance, that token will be used for token authentication by the server.
A more advanced use involves using an ASTokenIssueServices provider. Such a provider is an object implementing the ASTokenIssueServices protocol, which is returned in the queue delegate method queue:tokenIssueServiceProviderForSessionAtIndexPath: (ASTransferQueueDelegate-p). This object will be queried by the queue (using the protocol methods) to obtain tokens for sessions as they are activated by the queue. This method is more powerful than setting tokens directly on the session, because the queue will handle certain token errors (like "token expired" errors) by automatically requesting a new token for a session from the ASTokenIssueServices provider. When using an ASTokenIssueServices provider there is no need to set tokens directly on the session.
In general, token authentication is separate from account authentication and tokens may be used in conjunction with any form of account authentication. In practice when token authentication is used account authentication is often made of secondary importance by using the same account for all transfers and relying on token authentication as the primary transfer authorization mechanism (for instance one may embed a private key into the application and use this key for all account authentication).
Transfers initiated via web interfaces and carried out by Aspera Connect often use token authentication with a specific key for account authentication. The Aspera Mobile SDK for iOS provides a convenience method to configure an ASAccount instance to authenticate in the same manner as Aspera Connect. The convenience method is configureForDefaultTokenAuthentication (ASAccount). Note that this method prepares the account for account authentication in the most common scenario in which token authentication is used, but it is not required to call it in order to use token authentication.
1.8.8
