Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Overview

 

In apstrata, all requests must be  authenticated. There are three methods for authenticating apstrata requests:

1- Default signature: This is the most secure method of authentication because it requires hashing all content of a request along with the secret of the account or the password of the user and then sending the hash.

2- Simple signature: This is the easiest method of authentication. It requires hashing a few select parameters along with the secret of the account or the password of the user and then sending the hash. It is recommended for testing and for applications that do not have access to all parameters, like files, in a request.

3- Token-based authentication: This is the recommended method of authentication for applications that make most requests with apstrata users, as opposed to owners, for use with SSL encrypted connections over HTTP POST. It provides a similar experience to sessions since a token is generated and renewed over a period of time, without the need to generate a signature for every request.

 

The authentication roadmap for the apstrata database includes optional replay prevention.

Description

apstrata services only accept authenticated requests. Authenticating an apstrata service request means either sending it with the apsws.authSig parameter or a valid value for the apsdb.token parameter. Creating the signature parameter for owner requests requires the developer to know their authentication key (apsws.authKey) and their authentication secret. Creating the signature parameter for user requests requires the developer to know their authentication key (apsws.authKey), the user login, and the user password. generating tokens requires generating a user request to VerifyCredentials in order to generate a token and then sending the token with every consecutive request in order to authenticate it. The token needs to be constantly renewed and requires re-authentication when its lifetime expires. The authentication key and the secret will be provided upon registration. The user login and the password are chosen when creating an apstrata user. Note that the secret works as a password for accessing our services suite and hence your data.

Never reveal your authentication secret to a third party, an apstrata database affiliate will never ask for your secret. In case you feel that your authentication secret has been compromised, you can create a new one.

Two types of signatures exist, one which is more secure and complex to construct, and another version which is simpler to construct but less secure.

Token-based authentication

 

A token can be used to authenticate a user in place of a signature. This allows the creation of applications that do not need access to the users password which is required for signature generation. Tokens provide a layer of simplicity, but must obey the following restrictions:

1. Token-based authentication is enabled for user requests only. Owner requests must use signatures.

2. Token-based authentication is enabled under secure (https) connections only.

Tokens can be created or renewed using VerifyCredentials and can then be passed as a parameter to requests instead of the signature.

When no longer needed, tokens can be deleted and cleared using DeleteToken

Authenticating Requests for Users

Requests can be authenticated with user credentials (username/password). In order to create a user belonging to a customer: A user must be created using the SaveUser API action with a request signed by the customer's authentication key and authentication secret; a username and password will be used to create the user.

Signing a request with the customer's authentication key, and one of his users' username and password (a hash of the password) can be used to allow rich client applications to make requests to apstrata database without giving out the customer's secret.

Default Signature: Follow the steps in the Request Authentication section, and set the parameter apsws.authKey to be the username of the created user. Then calculate the HMAC-SHA1 hash string using the MD5 hash of the created user’s password.

Token-based Authentication: Follow the steps in the Request Authentication section about token-based authentication which is only allowed for users.

Simple Signature Type: Follow the steps in the Request Authentication section, and set the parameter apsws.authKey to be the username of the created user. Then use the MD5 hash of the created user’s password when creating the signature.

By using the user's username and password:

ValueToHash = [timestampValue][username][action name] [Md5hashFunction(new user password)]


Requests signed using the authKey and the sharedSecret without a username are called "owner" requests where owner is considered to be the db owner i.e. the apstrata database customer who holds the shared secret.

Note: ACL checking is skipped when the request is performed by owner.

  • No labels