Authentication

In order to use the interactive Reference section, you will need to properly authenticate. If you do not have credentials, you can request a sandbox account. Alternatively, you can inquire about purchasing a license, or request access for your company's account, via AB Support.

Once you have your partner ID and key, you can create signatures and start to make calls to the production version of AB Connect. From a high level, the signature is an HMAC SHA-256 hash of a message constructed in a specific format. Use the partner key that is given to you by AB Support for the hash key. The message has one required field (expires - expressed in seconds since epoch) and three optional values: user, method and resource. The delimiter between the fields is a bare newline character (no carriage return) typically denoted as "\n". The generalized form of the message is:

<expires>[\nuser][\nmethod][\nresource]

Here are some example messages and their interpretation:

  • 1508419888 - Access expires on October 19th 2017 at 1:31:28 PM ET. Note that expirations are expressed in Eastern time in the US.

  • 1508419888\nbmarley - Same expiration time but the signature is only valid for Bob Marley's account. Note that if you supply a user, the user.id field must include the same value in the URL parameters.

  • 1508419888\n\nGET - This signature can only be used for GET HTTP requests. Notice that the method is uppercase. This is a good approach when using AB Connect from public (or customer) facing web clients. It ensures that a hacker can't manipulate your Assets.

  • 1508419888\n\nGET\nstandards - This signature can only be used for GET requests to standards. Notice that the resource is lowercase. If you have a web client that allows users to browse standards but you want to keep your Asset metadata profiles private, this will limit the scope accordingly.

NOTES:

  • Each field can have only one value, so you can't mix methods or support multiple endpoints. E.g. if you want to allow read access to both Standards and Topics, you'll need to create two signatures and use the appropriate signature for each call.

  • While the expires (auth.expires), signature (auth.signature) and optionally the user (user.id) are included in the URL parameters, the method and resource values are inferred from the actual call being made so there is no need to pass those as URL parameters.

  • If you specify a resource, you must specify a method. Allowing "all methods" on one endpoint is not currently supported. So, for example, your message can not look like 1508419888\n\n\nassets.

Once you have calculated the signature, include the authentication parameters in the URL of your call to AB Connect. The general form of the parameters is:

&partner.id=<ID>&auth.signature=<signature generated above>&auth.expires=<signature expiry in seconds since epoch>

or if you are including a user ID:

&partner.id=<ID>&auth.signature=<signature generated above>&auth.expires=<signature expiry in seconds since epoch>&user.id=<user>

So if your partner ID is test_account and your key is ajk84Hjk93h59skaAJ8732 and you want to generate a read-only signature that expires on Wed Dec 06 2017 09:20:29 GMT-0500 (Eastern Standard Time)...

  • Your message would be: 1512570029\n\nGET

  • Your signature would be a base64 encoding of the HMAC SHA-256 hash of the message: Sdcfa9xgRAUzQnlLik5nKj1ntqdB85jFYyFCkNxwD/M=

  • URL encoding each parameter value and assembling the parameters together, the authentication portion of the URL would be: &partner.id=test_account&auth.signature=Sdcfa9xgRAUzQnlLik5nKj1ntqdB85jFYyFCkNxwD%2FM%3D&auth.expires=1512570029

You can use the following code examples as a starting point for constructing an authentication signature for use when calling AB Connect. Note that these examples do not necessarily follow coding best-practices - e.g. they do not have proper error handling in place. They are intended to be simple examples to show the concepts necessary to perform API authentication. Also note that these examples don't include any method or resource limiters in the signature.

Best Practices for Web Clients

Due to the nature of web clients, anything available to the client application can be accessed by the user. The user can view the source and use Inspect/Developer mode to access variable values, etc. For this reason, you need to be particularly careful with security measures. If you are accessing AB Connect directly from a web client, consider the following when creating your signatures:

  • Keep your partner key secret. Don't send it to the web client for any reason. If someone malicious gets a hold of your partner key, they can create any signature they want at any time they want and do damage to your Asset profiles. If you suspect your partner key has been compromised, contact AB Support and ask to have a new partner key issued.

  • Keeping your partner key secure means you need to generate the signature on the server side and embed the signature in the page as it is served to the client. Alternatively, you can create a service that generates signatures on request for your web clients. However, if you do that, you'll need to layer your own security model on top of that to ensure the web client making the request has permissions to access the AB Connect signature.

  • Make the life of the signature reasonably short. What is reasonable for your situation is up to you. Perhaps limit read capabilities to an hour and update (POST, PATCH, DELETE) to a few minutes. One thing to consider what is the user experience with the signature expires. Does the page force a re-load to gain a new token? Does it make an authenticated call to your server via AJAX to renew the signature? Does the user need to re-authenticate or do you trust a session cookie?

  • Limit the method to the minimum required capabilities. Most web clients will only need read access (e.g. if you are offering the user a Standards or Asset browser). If you need to change permissions, consider creating a separate, short-lived signature for those situations.

C#

See also the C# example project in the authentication folder of our github repository.

Perl

See also the Perl example project in the authentication folder of our github repository.

PHP

See also the PHP example project in the authentication folder of our github repository.

Python2 (2.5 or Higher)

See also the Python2 example project in the authentication folder of our github repository.

Python 3

See also the Python3 example project in the authentication folder of our github repository.

VB.Net

See also the VB example project in the authentication folder of our github repository.

Java

See also the Java example project in the authentication folder of our github repository.

node.js

See also the NodeJS example project in the authentication folder of our github repository.

Last updated

Was this helpful?