Overview
Apstrata Authentication Methods
| Excerpt |
|---|
In Apstrata, all requests must be authenticated. There are |
...
four methods for authenticating |
...
Apstrata requests: |
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
| Note |
|---|
The authentication roadmap for the |
...
Apstrata database includes optional replay prevention. |
Authentication Methods Description
apstrata database Apstrata services only accept authenticated requests. Authenticating an apstrata database Apstrata service request means either sending it with the apsws.authSig parameter or with 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 or generateToken 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
...
- are 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.
- Using a bearer token authentication enables users and devices to access protected resources without sending their credentials or tokens as parameters. Instead, users and devices can set in the Authorization header of any Apstrata HTTP request a bearer token that will be computed based on the application authentication key, their unique identifier and their Apstrata token.
| Warning |
|---|
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 |
...
generate 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.
Default Signature Type
By default, apstrata database will use a secure signature which depends on the data sent. It involves most of the data in the request, and it is calculated using the secret authentication key.
To create a signature:
1. Create a standardized string of the query string to be hashed
a. URL encode both the parameters and their values
i. In case of an attachment, the value would be the URL encoded hexadecimal representation of the MD5 hash of the file bytes (all capital letters)
ii. Example:
| Code Block |
|---|
MessageDigest messageDigest = MessageDigest.getInstance("MD5");
FileInputStream fis = new FileInputStream(filePath);
byte[] bytes = new byte[4096];
int readPos = fis.read(bytes);
while (readPos != -1) {
md5.update(bytes, 0, readPos);
readPos = fis.read(bytes);
}
String hashedValue = hexToString(messageDigest.digest()).toUpperCase();
|
...
c. Sort the parameters and their values by natural byte ordering (follow example below)
d. Append the name value pairs with an ampersand
2. Create the string to be hashed:
| Code Block |
|---|
String to hash = HTTPVerb (Upper case) + "\n" + encoded Http URL + "\n" + standardized string
|
...
3. Calculate the HMAC-SHA1 hash string using the secret authentication key
Please note that spaces and asterisk should be encoded as %20 and %2A respectively
Example:
| Code Block |
|---|
POST http://sandbox.apstrata.com/apsdb/rest/[authentication_key]/CreateStore
Host: host
.........
apsdb.store=myStore&additionalParam1=value1&apsws.time=1234567890
|
...
| Code Block |
|---|
additionalParam1=value1
apsdb.store=myStore
apsws.time=1234567890
|
...
| Code Block |
|---|
"POST\n
http%3A%2F%2Fsandbox.apstrata.com%2Fsandbox%2Dapsdb%2Frest%2Fauthenticationkey%2FCreateStore\n
additionalParam1=value1&apsdb.store=myStore&apsws.time=1234567890"
|
...
| Code Block |
|---|
HMAC-SHA1("secret", "POST\n http%3A%2F%2Fsandbox.apstrata.com%2Fsandbox%2Dapsdb%2Frest%2FmyKey%2FCreateStore\nadditionalParam1=value1&apsdb.store=myStore&apsws.time=1234567890")
|
...
| Code Block |
|---|
POST http://sandbox.apstrata.com/apsdb/rest/[authenticationkey]/CreateStore
Host: host
.........
apsdb.store=myStore&additionalParam1=value1&apsws.time=1234567890
$paramArr = array();
array_push(rawurlencode("apsws.time") . "=" . rawurlencode("1234567890"));
array_push(rawurlencode("apsdb.store") . "=" . rawurlencode("myStore"));
array_push(rawurlencode("additionalParam1") . "=" . rawurlencode("value1"));
sort($paramArr);
$stringToSign = "";
for($i = 0; $i <count($paramArr); $i++)
{
$stringToSign .= $paramArr[$i];
If($i <count($paramArr) - 1)
{
$stringToSign .= "&";
}
}
$stringToSign = "POST" . "\n" . rawurlencode (http://sandbox.apstrata.com/apsdb/rest/[authenticationkey]/CreateStore)
. "\n" . $stringToSign;
// assuming that the secret authentication key has the value "secret"
$signature = hash_hmac("sha1", $stringToSign, "secret");
|
Simple Signature Type
In order to use the simple signature, requests should specify the authentication mode by setting the value of the parameter “apsws.authMode” to “simple”. Each request must also specify the action name and the timestamp (apsws.time). A URL example would be:
http://sandbox.apstrata.com/apsdb/rest/ [authenticationkey]/CreateStore ?&apsws.time=1234567890&apsws.authMode=simple
First, construct the text to hash by doing:
| Code Block |
|---|
ValueToHash = [timestampValue][Authentication Key value][action name][secret]
|
...
| Code Block |
|---|
secret = qwerty
apsws.authKey = asdfg
apsws.time = 1234567890
action = CreateStore
valueToHash= 1234567890asdfgCreateStoreqwerty
|
...
The signature is then created by generating the Md5 hash of this text and using Hexadecimal characters:
| Code Block |
|---|
apsws.authSig = Md5hashFunction(valueToHash)
|
...
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