Technology Overview

Absio offers a suite of multi-language Software Development Kits (SDKs) that developers can use to build PKI-based authentication and data-level encryption directly into software applications and services, without having to manage keys and certificates, add hardware, or rely on a third-party service. Absio’s Serverless Encryption® technology automatically encrypts any type of data generated or processed by software, prior to being stored or transmitted, without needing to be connected to a central server. The Absio SDKs consume data objects and associated metadata from an application, service or webpage, and create an Absio Secured Container. Each data container has a unique encryption key. Data container keys are then uniquely encrypted for each User who has been given access to the content, allowing User-specific Access and Permissions to be added or revoked at any time without needing to re-encrypt the data container.

All key generation for PKI-based authentication and data encryption is performed automatically on the device, server or browser running the application or service using the SDK, not by a central key server. Absio Secured Containers, data container keys, Container Metadata, private Key Files and public keys can be stored wherever needed to support the data security, workflow, performance and availability requirements of your application. To reduce network latency impacts and enable local content to be encrypted and decrypted regardless of connectivity, encrypted data containers and container keys can be stored locally in an Obfuscating File System — a randomized directory of individually-encrypted, nonsensically-named objects with no identifying attributes. If application data will exist on multiple devices for multiple Users, the optional Absio Broker™ application can be used as a public key store, and for key and data backup, synchronization and exchange.

Developer Tools

Absio’s developer toolset consists of a suite of Software Development Kits (SDKs) and the optional Absio Broker application.

Absio Data Encryption SDKs

  • Multilanguage libraries that are compiled directly with software/applications.
  • Accessed via a simple Application Programming Interface (API).
  • The libraries handle all key generation, encrypt and decrypt processes.
  • Can optionally handle key and data content management.
  • SDKs are currently available in:
  • SDKs for Swift and C++ are in development.

Absio Broker Application

Data Elements

The Absio Developer Tools generate and can optionally manage the following Data Elements:

User

A User is an entity with a unique identifier (GUID generated by the Absio SDK) and a set of private and public key pairs. There are two main key types: those used for signing and signature verification, and those used for deriving encryption/decryption keys. A User’s private keys are automatically stored in an encrypted Key File. A User’s public keys can be registered with the Absio Broker application to make them available to other application Users, or can be managed directly by your application. These public keys are used to grant Access to Absio Secured Containers and validate User actions.

Users are able to create, read, update and delete Absio Secured Containers. Optionally, a User can share Absio Secured Containers with other Users, and add unique Permissions and/or lifespan controls.

Key File

An encrypted Key File is created for each User that contains the User’s private keys (both signing and derivation) and password reset information (if enabled). The Key File is encrypted with AES256 symmetric encryption using a key derived from the User’s password.

A passphrase may also be provided allowing the Key File to be synchronized between devices, as well as enabling secure password reset. By default, a User’s encrypted Key File is backed up by the Absio Broker application and stored locally in the Obfuscating File System or browser cache.

Absio Secured Container

An Absio Secured Container is the fundamental encrypted data structure in the Absio ecosystem, comprised of content and an optional header.

Content

  • The content is the data payload of the container.
  • Can be any form of data (bytes, files, streams, keys, etc.).
  • While there are no inherent limitations on the maximum size of the content, application performance and user experience may vary depending on platform limitations (particularly if encrypt/decrypt operations are performed in the browser).
  • The header can be any information about the content that is private or sensitive, or that needs to remain with the data wherever it goes.
  • The header content must be serializable as JSON.
  • It can be independently decrypted without downloading and/or decrypting the content.

Each Absio Secured Container has a unique set of secret keys. AES256 symmetric keys are used to individually encrypt the header and content using a different nonce for each. HMAC keys are used to produce a digest for header and content validation to mitigate content tampering. Copies of these secret keys are uniquely encrypted for each User that can Access the data container. This encryption process uses Static-Ephemeral Diffie-Hellman Key Exchange (DHKE) based upon a User’s public derivation key. This process ensures that the decryption of the secret keys for each Absio Secured Container can only be accomplished using the authorized User’s corresponding private key. Furthermore, the secret keys are signed with the creator’s private signing keys to help mitigate man-in-the-middle attacks.

Container Metadata

In addition to the header, which is cryptographically bound to the data container content, the Absio SDK enables additional metadata to be associated with an Absio Secured Container for the purposes of filtering or processing information without downloading and decrypting the data container itself.

Type

  • The type field is an optional piece of metadata that can be applied to describe the contents of the Absio Secured Container.
  • The type field is a string.
  • The type field is stored:

Generated Metadata

  • The following additional metadata is automatically generated by the Absio SDK:
    • ContainerID: Unique Absio Secured Container ID.
    • Created: Datetime object corresponding to when the Absio Secured Container was created.
    • CreatedBy: UUID of User that created the Absio Secured Container.
    • ModifiedAt: Datetime object corresponding to when the Absio Secured Container content was last modified.
    • ModifiedBy: UUID of User that last modified the Absio Secured Container content.
    • Length: Length (in bytes) of the Absio Secured Container.

Access and Permissions

Access

  • Absio Secured Containers (ASCs) can be shared with other Users in the Absio ecosystem. These can be Users registered with the Absio Broker application, or Users that have shared their IDs and public keys via the application or out of band.
  • Granting Access allows a User to define explicit Permissions for other Users to view and modify aspects of a data container’s content, header, type, and/or access list, as well as define when Access to the data container will expire.
  • Unless Permissions are explicitly defined, the User creating or updating the data container will be given full Permissions without an expiration. Note: if permissions are defined for other Users but not for the creating User, the creating User will have no permissions.

Permissions

  • The Permissions define how the Absio Broker application will respond to create, read, update and delete operations for a given data container.
  • The Absio SDK and Absio Broker application are enabled or disabled from performing certain operations based on these Permissions.
Permission Creator Default Other User Default Description
View Access true true Permission to view the full access list containing all other User’s IDs, expiration dates, and Permissions. Set to false to prevent a User from seeing other Users’ Access information for the data container.
Modify Access true false Permission to add, remove, or update all Users’ Access to a data container. Set to true to allow a User to modify Access to the data container.

NOTE: you should also set View Access to true if this is true. Otherwise, the User can modify the access list, but not include others who have access.
Decrypt Container true true Permission to Access the data container key required for this User to decrypt the data container. Set to false to prevent a User from being able to decrypt the data container’s content and header.
Download Container true true Permission to allow a User to download the encrypted data container. Set to false to prevent a User from accessing the encrypted data container.
View Container Type true false Permission to view the data container type field. Set to true to allow a User to see the data container type field.
Modify Container Type true false Permission to modify the data container type field. Set to true to allow a User to make changes to the data container type field (in events and container requests).
Upload Container true false Permission to upload changes to the data container’s content and header. Set to true to allow a User to upload changes to the content and header.

NOTE: If setting Upload Container to true, View Access and Modify Access should also be set to true. Otherwise this combination of Permissions will be rejected by the Absio SDK and Absio Broker application.

Expiration

  • Expiration time defines when Access to the data container will be revoked for the specified User.
  • If local storage is being utilized, the application can use this information to enforce revocation regardless of connectivity.

Obfuscating File System

If your application supports file storage, then the Absio SDK can handle the secure, local storage of encrypted content and keys. The local storage can be used as a cache allowing for offline access to data, as well as improving application performance (no need to request the keys and content from the Absio Broker application for access).

Local storage is performed in the Obfuscating File System. The Obfuscating File System creates random, nonsensical paths within the root directory for all files. This serves to remove any identifiable attributes (file name and associated content), ruining the economics of attempting to target specific files for brute-force decryption. Optionally, the content within the Obfuscating File System can be segregated by User ID.

Note: The Obfuscating File System structure is specific to the programming language utilized, and is therefore not portable. Thus, the directory structure created for Node.js will not work in the other (Python, C#, etc.) versions of the SDK. If local storage is desired across platforms, a language-specific Obfuscating File System will automatically be created for each application instance.

Example of the Obfuscating File System on a Windows® device.

Obfuscating File System

Providers

Providers handle creating, reading, updating and deleting Absio Data Elements in their dedicated location. The Absio SDKs include three standard Providers: Server, OFS and Server Cache OFS. The Absio SDKs also enable developers to build their own custom Providers for ultimate flexibility.

Server Provider

Use this Provider if you want all Data Elements to be stored and managed by the Absio Broker application. All create, read, update and delete Events are tracked by the Absio Broker application for each User. The Absio SDK calls the Absio Broker application to retrieve Events for the authenticated User, enabling synchronization of data containers across platforms and devices. This is the default Provider when no local application storage is available (browser-based applications).

OFS Provider

Use this Provider if you want all Data Elements to be stored and managed by the Obfuscating File System. This is an entirely local (file-system-based) Provider that does not require the use of the Absio Broker application. All create, update and delete operations only affect the local storage for the authenticated User. There is no Event system for local storage. Using this Provider, you can grant/modify Access for other Users in the system. However, the data is only stored locally, and you must import the User’s public keys into the Obfuscating File System (if they do not already exist).

Server Cache OFS provider

Use this Provider to take advantage of the benefits of both the Server and OFS Providers for high performance and data availability. This Provider stores and manages Data Elements with the Absio Broker application, but also uses the local Obfuscating File System storage as a cache to facilitate faster read times and allow for offline access. When Data Elements are requested, the local Obfuscating File System is queried first. If the Data Element is found (cache hit), it is returned immediately. If not (cache miss), the Absio Broker application is then queried. If the Data Element is found on the Absio Broker application, the Provider will store it in the Obfuscating File System cache before returning it to the caller, reducing latency on subsequent requests. This is the default Provider when local application storage is available.

Custom Provider

If you want to manage some or all Data Elements directly via your application, you can create a custom Provider. For example, you could create a Provider that uses the Absio Broker application to manage Users, Key Files and container keys, but stores the Absio Secured Containers on a local SAN or in a specific cloud service.

Events

If desired, the Absio SDK can use the Absio Broker application to track and distribute data container Events. An Event is generated any time a User accesses, creates, deletes or updates the content, header, container type and/or access list of an Absio Secured Container. The Absio SDK calls the Absio Broker application to retrieve Events for the authenticated User, enabling synchronization of data containers across platforms and devices. A developer can choose to retrieve all Events related to an authenticated User on each call, or can filter the Events by container ID, container type, action or starting event ID. Events are not cached in the Obfuscating File System.

An Event notification contains the following information:

  • ID: Integer value for the Event. Event IDs automatically increment.
  • Type: Indicates the Event is related to a data container.
  • Date: Datetime object corresponding to when the Event occurred.
  • Action: Always one of accessed, added, deleted or updated.
  • ContainerID: UUID of the data container the Event relates to.
  • ContainerType: Type metadata as specified upon creation or last update.
  • ClientAppName: Name of the application responsible for the action. This may or may not exist, depending on the settings configured in the application.
  • Changes: Information about what has changed.
  • RelatedUserID: UUID of User the Event relates to or was triggered by, if different from the authenticated User.
  • ModifiedAt: Datetime object corresponding to when the container content was last modified. It does not change when updating the access list, header, or container type and will be None in those cases.
  • ExpiredAt: Datetime object if the container has expired, or None otherwise.

Getting Started

This Quick start guide is intended to help you begin playing around with the Absio SDKs right away.

Need more info on the technology and tools? Check out The Basics section.

Want to dig deeper into the Absio SDKs? See our complete API documentation.

Looking to set up the Absio Broker application? Go to the Absio Broker deployment documentation.

Obtain API Key

The Absio SDKs require a valid API Key to communicate with the Absio Broker application. Thus, you cannot use the Server Provider or the Server Cache OFS Provider without a valid API Key.

Obtain an API Key by contacting us here or sending an email to [email protected].

An API key should be considered private and protected as such.

Install Library

Install the relevant Absio SDK libraries and any dependencies.

The libraries are available here:

Install-Package AbsioSDK -ProjectName "<MyProject>"
npm install absio-secured-container

// If using in browser, import into the front end application
pip install absio
      <repository>
          <id>absio-nexus</id>
          <url>https://nexus.absio.com/repository/maven-releases/</url>
      </repository>

      <dependency>
          <groupId>com.absio</groupId>
          <artifactId>absio-sdk</artifactId>
          <version>1.1.0</version>
      </dependency>

Initialize Module

Import and initialize the Absio secured container module.

If you are using the Absio Broker application to manage any data elements, you will need the URL of the Absio Broker application and your API Key.

The code examples that reference a provider are using the Server Cache OFS provider. They also are using the Absio sandbox server URL for the Absio Broker application.

Note for JavaScript Developers: We use Rollup to produce unique CommonJS and ES6 bundles for node and browser. Our goal is to make using our SDK as easy as possible. Contact us if you experience any issues or have suggestions to improve this.

The module and jsnext:main fields of the package.json reference the CommonJS and ES6 specific bundles for Node.js. The browser field of the package.json maps to the corresponding browser bundles. The browser bundle contains all external dependencies needed for execution, whereas the Node.js version does not.

If your project does not use a module bundling tool like Browserify or Rollup, then the dist/browser/index.min.js bundle can be imported directly in HTML and adds a window.securedContainer global.

<script src="node_modules/absio-secured-container/dist/browser/index.min.js"></script>
provider.Initialize("https://sandbox.absio.com", "your API key", "your application name");
// Import
import { register, create, initialize } from 'absio-secured-container';
 
// Initialize
var securedContainer = require('absio-secured-container');
await securedContainer.initialize('https://sandbox.absio.com', 'your api key');
import absio
absio.initialize(api_key='your api key')

Register Users

Create your Absio User accounts.

You will need a password and passphrase for each new User. The reminder is optional (to help you recall the passphrase).

After registering, your session will be authenticated. You do not need to authenticate a session after registrating.

The code examples are using the Server Cache OFS Provider directly or indirectly.

await provider.RegisterAsync("password", "passphrase", "reminder")
const newUserId = await securedContainer.register('password', 'reminder', 'passphrase');
absio.user.create('password', 'reminder', 'passphrase')

Authenticate

Log in with an existing Absio User account.

You will need the registered User’s ID, password and/or passphrase.

The code examples are using the Server Cache OFS Provider directly or indirectly. They show how to authenticate regardless of Key File location (stored in the Obfuscating File System or by the Absio Broker application).

await provider.LogInAsync(userIdGuid, "password", "passphrase");
await securedContainer.logIn('userId', 'password', 'passphrase');
absio.login('user_id', 'password', 'passphrase')

Create Container

Create an Absio Secured Container and grant Access to other registered Users.

The code examples are using the Server Cache OFS Provider directly or indirectly, and assume an authenticated session.

You will need the following to assemble the Absio Secured Container and grant Access:

  • Data object (content)
  • Access list (IDs of Users who can Access the content, their Permissions and Access expiration time)

Optionally, you can add a custom header and/or type descriptor to your data container. For more details, see the complete API documentation.

var sensitiveData = new byte[] {'a', 'b', 'c'};
var access = new ContainerAccessLevel[] {new ContainerAccessLevel(userId)};
var securedContainer = await provider.CreateAsync(sensitiveData, accessLevels: access);
const sensitiveData = new Buffer('Sensitive Data...000-00-0000...');
const containerId = await securedContainer.create(sensitiveData, { access: 'userId' });
container = absio.container.create(
  content=open('/some/sensitive/data.bin', 'rb').read(),
  access=['user_id'],
)

Get Container

Get an Absio Secured Container.

The code examples are using the Server Cache OFS Provider directly or indirectly, and assume an authenticated session. They show how to get a container with a known ID.

The container ID is returned during creation, or in an Event. For more details, see the complete API documentation.

// Get the Container with a known ID
var container = await provider.GetAsync(containerId);
// Get the Container with a known ID
const container = await securedContainer.get(containerId);
# Get the Container with a known ID
container = absio.container.get('container_id')

Update Container

Update an Absio Secured Container.

The code examples are using the Server Cache OFS Provider directly or indirectly, and assume an authenticated session. They show how to update the type field of a container with a known ID.

The update methods can be used to update any field specified in the options. Call the specific version of the update methods in order to update only what has changed. For details on updating other fields, see the complete API documentation.

// Update Type only - updates only the type
await provider.UpdateTypeAsync(containerId, "redefinedContainerType");
await securedContainer.update(containerId, { type: 'redefinedContainerType' });
absio.container.update(container_id, type='redefined_container_type')

Delete Container

Delete an Absio Secured Container.

The code examples are using the Server Cache OFS Provider directly or indirectly, and assume an authenticated session. They show how to delete a container with a known ID.

Note: This method permanently removes the authenticated User’s Access to a container within the context of the Provider used. This does not delete the content for all Users with Access. For more details, see the complete API documentation.

await provider.DeleteAsync(containerId);
await securedContainer.deleteContainer('containerId');
absio.container.delete('container_id') 

Change Provider

Change the default Provider.

If your application has access to local storage, the Server Cache OFS Provider is used by default. Otherwise, the Server Provider is used by default when no local application storage is available (browser-based applications).

The code examples show changing the default to the OFS Provider. For details on creating a custom Provider, see the complete API documentation.

Note: C# does not have a default Provider. It is up to the developer to reference the Provider of choice directly. There is not a generic interface or contract for Providers.

OfsProvider ofsProvier = new OfsProvider();
... // Initialize and use provider.
securedContainer.setCurrentProvider(securedContainer.providers.ofsContainerProvider);
import absio
absio.providers._default_provider = absio.providers.ofs

API Documentation

Visit the appropriate website below to find the complete language-specific API documentation:

Libraries

Visit the appropriate website below to download the language-specific Absio SDK libraries:

Overview

Absio Broker is a portable, Python application that can be used with the Absio SDKs for identity management (usage and distribution of public keys), and to store and route encrypted Data Elements. The Absio Broker application stores Access and Permission information to enforce which Users are able to view and modify aspects of a data container, and includes an Event system to track and distribute data container Events. If data is stored by the Absio Broker application, all data containers, container keys and Key Files are encrypted before they arrive.

The following information can be stored by the Absio Broker application:

The Absio Broker application is written in Python using the Flask framework and the Flask-RESTful third-party library. It utilizes Redis for file queueing and PostgreSQL for the database backend. The Absio Broker application can be installed on premise or in the cloud. All communication with the Absio Broker application is handled by the Absio SDK, so no separate API calls are required.

The Absio Broker application can be deployed via:

Choose How to Deploy

The various Absio Broker application deployment options offer tradeoffs depending on the ease of use and scalability required. Arguably, the simplest deployment option is the Virtual Machine, as it can be imported into a hypervisor and started right away. On the opposite end of the spectrum, the Python source distribution allows you to make custom code changes, install on your operating system of choice, and makes no assumptions about the database, cache, or web-server-tier architecture.

Here are the deployment options in order of increasing configurability:

  1. The Virtual Machine image is the quickest to deploy.
    • An SSL certificate is recommended, but the database, cache, and web server have all been preconfigured.
    • Your only option for scaling is vertical by increasing the specs for the host.
  2. The Docker image provides a nice balance between ease of use and customization, and is a great choice if Docker containers are already being used in your stack.
    • The tiers can be configured to your liking, but a default setup is provided with a sample docker-compose.yml file.
    • Scaling is both horizontal and vertical.
  3. The RPM allows you to quickly get started with a Red Hat-based OS.
    • The database / cache / web server tiers are entirely up to you to manage.
    • This is a good option if you already have existing RHEL machines and services for the other tiers.
    • Scaling is both horizontal and vertical.
  4. The Python source distribution allows full customization.
    • Recommended only for users needing to customize the code, or to install on another operating system.
    • Scaling is both horizontal and vertical.

Prerequisites

In order to run your own Absio Broker application instance, unless otherwise noted, you will need the following:

  • A PostgreSQL 9.6+ database
  • A Redis 3.2+ database / cache
  • A web server capable of proxying uWSGI (Nginx, Apache, etc.)
  • Credentials (access and secret keys) for an AWS S3-compatible object store
  • An SSL certificate

You will also need the usernames and passwords for each of these services / items, if they have been configured to require authentication.

Note: This guide does not cover the installation and configuration of these external resources.

VM Deployment

Hypervisors

The following hypervisors are supported:

After obtaining the Absio Broker virtual machine image from Absio, import the image into your hypervisor and power it on.

Note: Details for the import process will vary depending upon the hypervisor you are using. Consult your hypervisor’s documentation for that information.

You may log in to the console using absio as the initial root password. You will be required to change the password upon first login.

Configuration

The application needs to be configured before it can run properly. Begin by editing the /etc/absio/server.conf file. The file should have some values prepopulated, but others need your specific information. The file should contain the following content:

# AWS Specific Configuration
AWS_S3_BUCKET = ‘The name of your S3 Bucket in AWS where all encrypted content shall be stored.’
AWS_S3_REGION = ‘Which region is your S3 Bucket in?  e.g. us-west-2’
AWS_ACCESS_KEY = ‘Your AWS provided access key that has permissions to access your S3 Bucket.’
AWS_SECRET_KEY = ‘The secret key associated with your AWS access key.’

# For cookies!
SECRET_KEY = ‘A secret value’

All values should be quoted.

The SECRET_KEY value should be a random value and is used for session cookies. For example, it can be populated with the output of the following command:

openssl rand -hex 32

After the configuration has been set, the VM may be rebooted.

Verification

After powering on the VM, determine its public IP address. Exact details for this will vary, dependening upon the networking configuration that has been applied.

Then, navigate to the following URLs:

If both URLs are successfully reached, your Absio Broker application is operational.

Docker Deployment

Docker Image

When you purchase an Absio Broker Docker deployment license, you will be granted credentials to the Absio Docker Registry. The URL is dockerhub.absio.com:5000.

The Absio Broker Docker image provides the following components:

  • API as an uWSGI application
  • Web frontend for management as an uWSGI application
  • Background worker processes
  • Task scheduler

Supported Tags

The following tags are supported when pulling from the registry:

  1. 1.0.2
  2. latest

Environment Variables

The application needs a small amount of configuration before it can run properly. The following environment variables are required:

Configuration Key Value
AWS_S3_BUCKET The name of your S3 Bucket in AWS where all encrypted content shall be stored.
AWS_ACCESS_KEY Your AWS provided access key that has permissions to access your S3 Bucket.
AWS_SECRET_KEY The secret key associated with your AWS access key.
REDIS_URL The URL to your Redis cache. This is where the server will store transactional data and background task information.
CACHE_REDIS_URL The URL to your Redis cache. This is where the server stores cached client responses, and should ideally be a different Redis database than REDIS_URL.
SQLALCHEMY_DATABASE_URI The URL to your PostgreSQL database.

Not all components provided by the Absio Broker image require all the environment variables.

Configuration

The following is a sample docker-compose.yml file. It utilizes existing public Redis, PostgreSQL, and Nginx images to provide the prerequisites.

version: '2'

services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    environment:
      - DEFAULT_HOST=api.absio.local

  migration:
    image: absio
    entrypoint: bash -c 'absio-broker-manage db create && absio-broker-manage db populate && absio-broker-manage alembic upgrade'
    depends_on:
      - db
      - redis
    links:
      - db
      - redis
    environment:
      - SQLALCHEMY_DATABASE_URI=postgresql://user:[email protected]/api
      - REDIS_URL=redis://redis:6379/0
      - CACHE_REDIS_URL=redis://redis:6379/1
  api:
    image: absio
    command: ['api']
    restart: always
    depends_on:
      - migration
    links:
      - redis
      - db
    environment:
      - REDIS_URL=redis://redis:6379/0
      - CACHE_REDIS_URL=redis://redis:6379/1
      - SQLALCHEMY_DATABASE_URI=postgresql://user:[email protected]/api
      - AWS_S3_BUCKET=my bucket name
      - AWS_ACCESS_KEY=access key for AWS
      - AWS_SECRET_KEY=secret key for AWS
      - VIRTUAL_HOST=api.absio.local
      - VIRTUAL_PROTO=uwsgi

  admin:
    image: absio
    command: ['frontend']
    restart: always
    depends_on:
      - migration
    links:
      - redis
      - db
    environment:
      - REDIS_URL=redis://redis:6379/0
      - CACHE_REDIS_URL=redis://redis:6379/1
      - SQLALCHEMY_DATABASE_URI=postgresql://user:[email protected]/api
      - VIRTUAL_HOST=admin.absio.local
      - VIRTUAL_PROTO=uwsgi

  worker:
    image: absio
    restart: always
    command: ['worker']
    depends_on:
      - migration
    links:
      - redis
      - db
    environment:
      - REDIS_URL=redis://redis:6379/0
      - CACHE_REDIS_URL=redis://redis:6379/1
      - SQLALCHEMY_DATABASE_URI=postgresql://user:[email protected]/api
      - AWS_S3_BUCKET=my bucket name
      - AWS_ACCESS_KEY=access key for AWS
      - AWS_SECRET_KEY=secret key for AWS
  scheduler:
    image: absio
    restart: always
    command: ['scheduler']
    depends_on:
      - migration
    links:
      - redis
    environment:
      - REDIS_URL=redis://redis:6379/0
      - CACHE_REDIS_URL=redis://redis:6379/1

  redis:
    image: redis:3.2.9

  db:
    image: postgres:9.6
    environment:
      - POSTGRES_PASSWORD=password
      - POSTGRES_USER=user
      - POSTGRES_DB=api

Verification

Once the docker-compose.yml file is in place, you may run docker-compose up to launch the entire system. Note: make sure to set your credentials for the environment variables.

You may verify that it is operational by visiting one of the following URLs in a web browser:

Note: Depending upon your Docker configuration, you may need to modify your system’s hosts file to point these domains to localhost.

Scaling

At this point, the different services can all be scaled individually. For example, if the API is experiencing heavy load, it can be scaled up by executing docker-compose scale api=10. The Nginx configuration will automatically be updated and requests will automatically be proxied to the new instances.

Security

In a real production system, the web server should be utilizing HTTPS and redirecting all HTTP traffic to it. Additionally, the frontend interface should not be exposed to the public.

RPM Deployment

Installation

The Absio Broker RPM can be installed on CentOS 7 or RHEL 7 via the Absio public repositories.

To create and enable the Absio public repository, create the /etc/yum.repos.d/absio.repo file with the following contents (Note: make sure to replace the $USER and $PASSWORD values with the credentials supplied by Absio):

[absio]
name=Absio Packages for Enterprise Linux $releasever - $basearch
baseurl=https://$USER:[email protected]/CentOS/7/$basearch
enabled=1
gpgcheck=1
gpgkey=https://$USER:[email protected]/CentOS/RPM-GPG-KEY-absio

To install the Absio Broker RPM, execute the following command:

yum update && yum install absio-broker

Configuration

The application needs to be configured before it can run properly. Begin by creating and editing the /etc/absio/server.conf file. The file should contain the following content:

# AWS Specific Configuration
AWS_S3_BUCKET = ‘The name of your S3 Bucket in AWS where all encrypted content shall be stored.’
AWS_S3_REGION = ‘Which region is your S3 Bucket in?  e.g. us-west-2’
AWS_ACCESS_KEY = ‘Your AWS provided access key that has permissions to access your S3 Bucket.’
AWS_SECRET_KEY = ‘The secret key associated with your AWS access key.’

# For cookies!
SECRET_KEY = ‘A secret value’

# Database and Cache
SQLALCHEMY_DATABASE_URI = ‘postgresql://user:[email protected]/api’
REDIS_URL = ‘redis://user:[email protected]:6379/0’
CACHE_REDIS_URL = ‘redis://user:[email protected]:6379/1’

All values should be quoted.

The SECRET_KEY value should be a random value and is used for session cookies. For instance, it can be populated with the output of the following command:

openssl rand -hex 32

The SQLALCHEMY_DATABASE_URI value must provide access to a PostgreSQL 9.6+ database and must conform to the formats described here. Similarly, the REDIS_URL and CACHE_REDIS_URL values must provide the Absio Broker application with access to a Redis 3.2+ instance. The two values may be identical, but it is recommended to separate into different databases so that cache may be cleared efficiently without impacting other data sets. The formats for these values are described here.

As the /etc/absio/server.conf file contains sensitive information, the file permissions should be managed to restrict access to only the absio user:

chown absio:absio /etc/absio/server.conf

Database Initialization

To create and populate the Absio Broker’s database tables, execute the following commands:

/opt/absio/absio-broker/bin/absio-broker-manage db create
/opt/absio/absio-broker/bin/absio-broker-manage db populate

The output of the create command should indicate that tables were created and it is at the latest (HEAD) revision. The populate command will output an API Key. This key may be used by applications utilizing the Absio SDKs. Additional API Keys can be generated using the administrative frontend uWSGI application.

Operation

First, the Absio Broker services should all be enabled such that when the system boots, they all begin running:

systemctl enable absio-api absio-frontend absio-scheduler absio-worker.target

With all the pieces now in place, it is time to start up the Absio Broker application:

systemctl start absio*

You may check the status:

systemctl status absio*

If all has gone well, all services will be operational. If not, investigate the log messages to see what is preventing a successful startup. The API uWSGI application will be listening on port 3031, while the Administrative uWSGI application will be on port 3032.

Python Deployment

Prerequisites

These prerequisites are in addition to the main set of Absio Broker prerequisites. As they are highly system dependent, no specific instructions are provided. Consult your system’s documentation if you need guidance.

  • Python 3
  • Python 3 Virtualenv
  • PostgreSQL development header files (e.g. the postgresql96-devel pkg)
  • absio user belonging to an absio group

These instructions provide information for configuring the systemd init system. If your OS has another init system, the general concepts will need to be ported to your OS.

Installation

It is highly recommended to follow Python best practices by installing the package into a Virtual Environment. You may create the Virtual Environment and install the Absio Broker package:

python3 -m venv /opt/absio/absio-broker/
source /opt/absio/absio-broker/bin/activate
pip install /path/to/absio-broker-1.0.2.tar.gz

Install a uWSGI server:

pip install uwsgi

Configuration

The application needs to be configured before it can run properly. Begin by creating and editing the /etc/absio/server.conf file. The file should contain the following content:

# AWS Specific Configuration
AWS_S3_BUCKET = ‘The name of your S3 Bucket in AWS where all encrypted content shall be stored.’
AWS_S3_REGION = ‘Which region is your S3 Bucket in?  e.g. us-west-2’
AWS_ACCESS_KEY = ‘Your AWS provided access key that has permissions to access your S3 Bucket.’
AWS_SECRET_KEY = ‘The secret key associated with your AWS access key.’

# For cookies!
SECRET_KEY = ‘A secret value’

# Database and Cache
SQLALCHEMY_DATABASE_URI = ‘postgresql://user:[email protected]/api’
REDIS_URL = ‘redis://user:[email protected]:6379/0’
CACHE_REDIS_URL = ‘redis://user:[email protected]:6379/1’

All values should be quoted.

The SECRET_KEY value should be a random value and is used for session cookies. For instance, it can be populated with the output of the following command:

openssl rand -hex 32

The SQLALCHEMY_DATABASE_URI value must provide access to a PostgreSQL 9.6+ database and must conform to the formats described here. Similarly, the REDIS_URL and CACHE_REDIS_URL values must provide the Absio Broker application with access to a Redis 3.2+ instance. The two values may be identical, but it is recommended to separate into different databases so that cache may be cleared efficiently without impacting other data sets. The formats for these values are described here.

As the /etc/absio/server.conf file contains sensitive information, the file permissions should be managed to restrict access to only the absio user:

chown absio:absio /etc/absio/server.conf

Database Initialization

To create and populate the Absio Broker’s database tables, execute the following commands:

/opt/absio/absio-broker/bin/absio-broker-manage db create
/opt/absio/absio-broker/bin/absio-broker-manage db populate

The output of the create command should indicate that tables were created and it is at the latest (HEAD) revision. The populate command will output an API Key. This key may be used by applications utilizing the Absio SDKs. Additional API Keys can be generated using the administrative frontend uWSGI application.

Operation

The Absio Broker package provides two uWSGI applications: the API and the Administrative Frontend. In addition, there are background workers and a task scheduler that need to operate. The enabling of these processes and the ability to start / stop / restart them is easily controlled using the systemd init system. The source distribution provides, but does not install, sample configuration files for these purposes.

Extract the sample configuration files from the source distribution:

tar xf absio-broker-1.0.2.tar.gz -C /etc/systemd/system absio-broker-1.0.2/data --exclude="*.ini" --strip-components=2

These files may need to be tweaked, depending upon:

  • The location of your Python Virtual Environment
  • Whether or not you’ve created an absio user and group
  • If you want to apply any tuning to the uWSGI configuration, etc.

Once you are satisfied with their values, you should configure the services to start automatically at boot:

systemctl enable absio-api absio-frontend absio-scheduler absio-worker.target

With all the pieces now in place, it is time to start up the Absio Broker application:

systemctl start absio*

You may check the status:

systemctl status absio*

If all has gone well, all services will be operational. If not, investigate the log messages to see what is preventing startup. The API uWSGI application will be listening on port 3031, while the Administrative uWSGI application will be listening on port 3032.

When the system is rebooted, the services should all be started automatically.

Support and Bug Reporting

General Support and Feedback

Please contact us at [email protected] if you experience any issues using this site, want to submit feeback, or have general questions about the technology.

Bug Reporting

Please use the relevant GitHub Issue Tracker to report any bugs.

Software License Agreement

1. INTRODUCTION.

a. Use of Software Subject to Agreement. Your use of our software (referred to collectively as the “Software” in this document) is subject to the terms of this agreement between you and us, as amended from time to time (the “Agreement”).

b. Acquisition of Licenses. You acquire Licenses and related services subject to this Agreement by submission of a Purchase Order(s) and payment of amounts due thereunder or by making a credit card payment specifying the type, quantity and License Term of the Software, as a result of which you are entitled to the rights set forth in this Agreement.

c. Parties. The term “You” or “you” means the individual, company, entity or organization which is executing or otherwise taking action to be bound by this Agreement; “we” or “us” means Absio Corporation, a Colorado corporation, and “both of us” means both you and us.

2. ACCEPTING THIS AGREEMENT.

a. Agreement to Terms. Your use of our Software is subject to your acceptance of the terms of the Agreement whether by (i) clicking to accept or agree to this Agreement, where this option is made available to you; (ii) by executing a Purchase Order referring to this Agreement; (iii) by paying an invoice referring to this Agreement; (iv) by executing this Agreement; or (v) by actually using the Software.

b. Acceptance of Terms by a Company, Entity or Organization. If you are entering into this Agreement on behalf of an entity, company or organization, you represent that you have the authority to bind your company, entity or organization to this Agreement.

3. DEFINITIONS. The following terms used in this Agreement have the specific meanings set forth below:

a. “Add-on Module” means the portion of the Software, if made available, that adds new functionality to the SDK, but is not required to be installed to ensure continued functioning of Application(s).

b. “Agreement” is defined in section 1(a).

c. “Application” is a software application you create which incorporates the Software.

d. “Broker™” means the portion of the Software, if required, enabling user identity management, storage of public encryption keys, the routing and sharing of content or encryption keys and, if applicable, the backup storage of encrypted content or private encryption keys.

e. “Business Days” means days that occur Monday through Friday, exclusive of observed holidays. If any event occurs during a Business Day, and the response is designated in “Business Days,” the deadline for such event to occur shall be prior to the end of the Standard Support Hours on that number of following Business Days. For example, an event occurring on Monday (at any time) for which one Business Day response is committed is due to be responded to by 7:00 pm Mountain Time Tuesday. An event occurring on Monday for which five Business Days response is committed to is due to be responded to by 7:00 pm Mountain Time on the subsequent Monday.

f. “Business Hours” has the following meaning: if any event occurs during Standard Support Hours, and the response is designated in “Business Hours,” such time period shall mean actual hours (even if such period extends beyond the normal end of Standard Support Hours). If any event occurs outside of Standard Support Hours, and the response is designated in “Business Hours,” such time period shall mean actual hours commencing upon the opening of business on the next Business Day.

g. “Customer” means your customer to whom you sell or license the Application(s).

h. “Developer” means an individual person engaged in the development of Application(s), whether or not such Developer uses the Software directly in the course of his or her work.

i. “Extraordinary Circumstances” include fire, flood, earthquake, elements of nature or acts of God, acts of war, terrorism, riots, civil disorders, rebellions or revolutions, strikes, lockouts, labor difficulties, generalized internet interruptions (through denial of service, worms, telecommunications problems and the like) or any other cause beyond our reasonable control.

j. “Feedback” is defined in section 10(b).

k. “Installed Instance” means a single physical or virtual installation of the Software.

l. “License” means the acquisition of the particular use rights (via payment and agreeing to the terms of this Agreement), and with the rights the responsibilities, provided in this Agreement.

m. “License Term” means the period for which you have acquired the right to use the Software, pursuant to this Agreement and any Purchase Order.

n. “Licensee” means you and/or any of your Customer(s) using your Application(s).

o. “Location” means a physical or virtual location where an Application is used.

p. “Major Release” means a change to the Software which requires a change to the Application to consume.

q. “Minor Release” means a change to the Software provided according to a normal development cycle, which does not generally require a change to the Application to consume.

r. “Patch Release” means a change to the Software provided outside the normal development cycle, which does not generally require a change to the Application to consume.

s. “Purchase Order” means a separate document itemizing the Software you are licensing pursuant to this Agreement, the License Term and the cost of such License(s).

t. “Sale” or “sell” and other similar terms, when used in connection with the marketing and distribution of any of the Software shall mean the licensing of such materials, and shall not be deemed for any purpose to mean a transfer of title or other rights of ownership to the Software.

u. “SDK” means the portion of the Software enabling, among other functions, and as applicable to your Application(s), user/device registration, key generation and management, encryption and decryption, access and use controls, source and integrity authentication, and the obfuscated storage of encrypted content and encryption keys.

v. “Software” is defined in section 1(a).

w. “Standard Support Hours” means from 8:00 am to 5:00 pm, Mountain Time, Monday through Friday, exclusive of observed holidays.

x. “Trial License” is defined in section 4(c)(iii).

y. “Trial Purchase Order” provides the terms and conditions of a Trial License.

z. “Updates” means Major Releases, Minor Releases and Patch Releases.

4. LICENSE FROM US.

a. Grant of License – Usage in General. Subject to this Agreement, we give you a personal, worldwide, non-exclusive right to use the Software in object code form only (except as otherwise specifically set forth below) for the purposes set forth below, depending on the particular License you have acquired. You may use the Software solely for the purpose of designing, developing and testing your Application(s) and (as subject to the provisions below) using such Application(s) internally or making them accessible or distributing them to third parties.

You may distribute the Application(s) you make containing our Software subject to the limitations of and type of use set forth below and in any Purchase Order, and subject to the following conditions: (i) you may not permit further redistribution of our Software by your Customer(s); (ii) you must distribute your Application(s) under a written agreement that prohibits reverse engineering, decompilation or disassembly of the Application(s) and requires your Customer(s) of the Application(s) to abide by the conditions stated in this Agreement; and (iii) without our consent, or as required below, you may not use our name, logo or trademarks to market your Application(s).

b. License Grant – Length of Term. The provisions of this Agreement are effective unless terminated. Following the expiration of the applicable License Term, you may no longer deploy new units of Application(s) incorporating the Software. Unless otherwise expressly prohibited by this Agreement, however, your Customer(s) continue to have the right to use Application(s) incorporating the Software supplied to them prior to the expiration of the related License Term. Any use of the Software beyond the scope of this Agreement or any Purchase Order is subject to payment of additional License fees.

c. Licensing Models.

i. In General. The Software includes the SDK and may include Add-on Modules and Broker™, if applicable. Your License requirements will be determined by the number of your Developers, the number of Installed Instances or whether the Application(s) are installed in a single Location or multiple Locations. The purchase price(s) for your License to the Software are specified on a Purchase Order.

ii. Trial Option. We may supply “Trial Licenses” for evaluation by you prior to purchasing a paid License. If your Software is designated as supplied under a Trial License, the terms of that Trial License will be specified on a Trial Purchase Order.

iii. U.S. Government End Users. The Software is “Commercial Computer Software” as defined in DFARS 252.227-7014, and “Restricted Computer Software” as defined in FAR 52.227-14, Rights in Data-General, including Alternate III, as applicable, with “Limited Rights,” in accordance with this Agreement’s terms and conditions. We must be notified in advance of any license grants to United States Federal Governmental entities.

5. LIMITATION ON YOUR USE.

a. Restrictions on Use. You may not (and you may not permit anyone else, on your behalf or otherwise to) copy, disassemble, modify, create a derivative work of, reverse engineer, decompile or otherwise attempt to extract the source code of the Software or any part thereof.

b. Compliance with Laws. You agree to use the Software only for purposes, and in a manner, permitted by (i) this Agreement and (ii) any applicable law, regulation or generally accepted practices or guidelines in the relevant jurisdictions including, without limitation, any regulations of the United States Bureau of Export Administration and other applicable governmental agencies (including all applicable US export restrictions).

c. Restrictions on Sublicense or Assignment. This Agreement and any License granted under this Agreement are personal to you, and do not include the right to sublicense your rights under this Agreement to any third party. You may not transfer or assign, by operation of law or otherwise, this Agreement or your License to any third party without our prior written consent, which may be withheld in our sole discretion for any reason or no reason. Notwithstanding the foregoing, you may permit your employees, consultants or other third-party service providers (collectively, “Personnel”) to access and use the Software on your behalf; provided that you shall be responsible for ensuring that your Personnel comply with this Agreement and any applicable end user license agreement or terms and conditions to which they assent. If you acquire a third party entity or acquire substantially all the assets or equity of a third party entity, or are acquired by a third party, in each case, whether by merger, change in control, sales of assets, consolidation or otherwise, such event shall be considered an assignment of this Agreement for this purpose. Any assignment or attempted assignment in violation of this Agreement shall be of no effect, and shall constitute a breach of this Agreement and result in the immediate and automatic termination of your license rights under this Agreement; any renewal of such rights shall, if then available, be at our sole discretion, and will be on terms and conditions applicable at the time of such renewal. You may not create a library that exposes or wraps functionality of the Software to a non-licensed party.

d. Additional Restrictions.

i. Maximum Number of Applications per License. Your License permits you to incorporate our Software into Applications you build. Your Purchase Order(s) may specify the maximum number of Applications you may build with a single License.

ii. Building Custom Applications for Multiple Customers. If you build custom/bespoke Applications for multiple Customers, you must purchase a separate License for each Customer.

6. SUBSEQUENT OR PREVIOUS VERSIONS OF THE SOFTWARE; MULTIPLE PHYSICAL COPIES.

a. Future Versions. The License granted to you under this Agreement is for the current version of the Software as of the time we make such version available to you under this Agreement. We may release future versions of the Software under this Agreement or a different agreement. Nothing in this Agreement is a commitment to you of compatibility between the Software and any future versions of the Software. This Agreement shall apply to any such updated Software made available to you except as otherwise expressly agreed in connection with such updated Software.

b. Upgrades of Previous Versions. If the Software provided to you is an upgrade or revised version of the Software previously provided to you under this Agreement or a predecessor agreement, you may not loan, rent, lease or otherwise transfer the original non-upgraded Software to another user or a separate computer. If the Software is an upgrade of a component of a package of software programs that you licensed as a single product, the Software may be used and transferred only as part of that single product package and may not be separated for use by another user or on a separate computer.

c. Multiple Physical Copies. You may receive the Software in more than one medium. Receipt of more than one copy of the Software (either on physical media or by multiple downloads or otherwise) does not entitle you to any additional rights to the Software. Your rights to use the Software derive from this Agreement and the License related hereto, not from any rights to ownership of tangible media, which if provided is only provided for your convenience.

7. SUPPORT OBLIGATIONS. The following provisions set forth your rights concerning maintenance and support of the Software. Any such services are provided only during the License Term.

a. General. Our support obligations for the Software are comprised of the following:

i. Updates. We will make available to you, at no additional charge, all Updates to the Software which we make generally available to our customers during your License Term.

ii. Versions Supported. We will not be responsible for support services for any version of the Software other than the current and previous Major Release of the Software, provided that we will support each Major Release (and the latest Minor Release(s) and Patch Release(s) made available with respect thereto) for a period of not less than one year from initial release of the Major Release.

iii. Problem and Error Resolution. We will investigate all potential errors related to the Software’s nonconformance to any documentation we provide, so long as you have notified us in writing (including via email and via submission to a support site or portal we make available to you) during the License Term. We will make commercially reasonable attempts to substantiate the existence of the problem or error, evaluate the seriousness of the problem’s effect on you and provide a workaround or resolution within the time frame established in the Error Reporting and Priority Guidelines. This does not guarantee that the resolution will include an update to the Software that will resolve or fix the reported issue.

iv. Telephone Consultation. We will provide reasonable telephone consultation to assist in the implementation and utilization of the Software during our Standard Support Hours. We may require that you submit a support request through a web support portal, depending on the classification of assistance required.

b. Error Reporting and Priority Guidelines.

i. Contacting our Support. Requests, other than bug submissions, may be made by telephone at (720) 836-1225, or via email at [email protected].

ii. Submitting Bugs. Bugs must be reported to the relevant submission portal as described at http://docs.absio.com.

iii. Classification of Errors. Upon receipt of requests for support, we classify support calls on the following basis:

Priority Priorities Assigned Under These Guidelines
1 Licensing issues related to deployment of the Software
2 Produces an emergency situation in which the Software is inoperable, or fails catastrophically
3 Produces a detrimental situation in which performance (throughput or response) of the Software degrades substantially under reasonable loads, such that there is a severe impact on use; one or more main functions or commands is inoperable; or the use is otherwise significantly impacted; licensing issues not related to the deployment of the user’s product.
4 Produces an inconvenient situation in which the Software is usable, but does not provide a function in the most convenient or expeditious manner or produces incorrect results, and the user suffers little or no significant impact.
5 Any other support issue, including requests for enhancement of documentation changes.

iv. Response Time. We shall, after receipt and classification, use commercially reasonable efforts to respond during Standard Support Hours to each notification as indicated below, with a resolution of the issue as indicated below:

Priority Receipt Acknowledged Resolution Goal
1 4 Business Hours 1 Business Day – correction to be issued when tested and available
2 4 Business Hours 2 Business Days – correction to be issued when tested and available
3 4 Business Hours Correction to be issued when tested and available
4 4 Business Hours Correction to be included in a future release, on a business justifiable basis
5 4 Business Hours Request may or may not be include in a future release, at our discretion
  • Receipt Acknowledged: time for our operational staff to respond to your notification and resolution commences.

  • Resolution Goal: if availability is not restored by this time, the issue will be escalated to a manager.

THESE RESPONSE TIMES AND RESOLUTION GOALS ARE NOT APPLICABLE TO TRIAL LICENSES.

c. Conditions for Support Provided by Us. We provide a second level of support for those problems that you cannot reasonably be expected to resolve for yourself. Accordingly, our performance under the above criteria is conditioned upon your compliance with the following conditions of support:

i. You must provide (or at least disclaim any requirement of ours to provide) first line support to your users (and your Customer(s)’ users);

ii. You must ensure that the Software is used only in combination with other software, devices or hardware recommended or specified by us as being compatible with the Software, and ensure a stable network environment with adequate capacity. In addition, you are expected to provide a technically qualified single point of contact for coordination of support with us;

iii. You must install (or cause your Customer(s) to install) all Updates we make available to you. We are not responsible for support services with respect to the Software if you (or the Customer(s)) have refused to permit updating of the Software by all applicable Minor Releases and Patch Releases or if you have not ensured that hardware and network services are correctly configured and operating according to specifications, and operating system software and other third-party software is current, and has all manufacturer/supplier-recommended updates and patches;

iv. You must provide us with reasonable access (remote or on-site, as needed by us) to the equipment, the Software and all relevant documentation and records related to a reported issue, and such reasonable assistance as we may request, including sample output and other diagnostic information, in order to assist us in providing support;

v. We are not responsible for support services to the extent arising in connection with Extraordinary Circumstances.

d. Services not Included. Support services do not include any of the following:

i. Custom programming services;

ii. On-site support, including installation of hardware or any third-party software;

iii. Support of any Software not covered by this Agreement; or

iv. Training.

8. PUBLICITY. You agree to be identified as a customer of ours and agree that we may refer to you by name, trade name and trademark, if applicable, and may briefly describe your business in our marketing materials and website. Your hereby grant us a license to your name and any of your trade names and trademarks solely in connection with the rights granted to us pursuant to this section.

9. PAYMENT.

a. Payment. You agree to pay all charges, recurring fees, applicable taxes and other charges at the rates in effect for the billing period in which those charges are incurred based on the applicable License(s) and/or Purchase Orders. All payments shall be made at our address indicated in this Agreement or at such other address as we may from time to time indicate by proper notice hereunder. All invoices are due and payable within thirty (30) days of our date of invoice. Interest shall be payable at the rate of one and one-half percent (1.5%) per month or at the maximum rate permitted by law, whichever is less, on all overdue and unpaid invoices until paid in full. All fees are denominated and to be paid in United States Dollars and are exclusive of any applicable taxes. You shall pay, indemnify and hold us harmless from all sales, use, value added or other taxes of any nature, other than personal property or taxes on or measured by our net or gross income, including penalties and interest, and all government permit or license fees assessed upon or with respect to any fees.

b. Billing Disputes. You must inform us of any billing problems or discrepancies within ninety (90) days after they first appear on your account statement or invoice. If you do not bring them to our attention within ninety (90) days, you agree that you waive your right to dispute such problem or discrepancies.

c. Consequences of Nonpayment. In the event we are unable to collect payment from you in accordance with this Agreement, in addition to reserving all other rights we may have hereunder, this Agreement shall terminate and the provisions of Section 11(c) shall apply.

10. PROPRIETARY RIGHTS.

a. Ownership of Intellectual Property. We (or our licensors) own all legal right, title and interest in and to the Software, including any intellectual property rights that subsist in the Software (whether those rights happen to be registered or not, and wherever in the world those rights may exist). The Software may contain information that is confidential to us (including, without limitation, any information so designated) and you shall not disclose such information to any third party without our prior written consent.

b. Content. Suggestions. You may voluntarily provide suggestions, comments or other feedback (“Feedback”) to use with respect to items or information provided by us under this Agreement. We are not required to hold your Feedback in confidence, and your Feedback may be used by us for any purpose without obligation of any kind. Incorporation of your Feedback into our materials or products does not affect our exclusive ownership of such materials by us.

c. Notices/Protection of Proprietary Rights. You may not remove, obscure, or alter any proprietary rights notices (including copyright and trademark notices) that may be affixed to or contained within the Software. In using the Software, you will not use any trademark, service mark, trade name, or logo of any company or organization in a way that is likely or intended to cause confusion about the owner or authorized user of such marks, names or logos. Nothing in this Agreement gives you a right to use any of our trade names, trademarks, service marks, logos, domain names, and other distinctive brand features without obtaining, in each instance, our prior written consent.

11. TERM.

a. Term. This Agreement is effective until terminated as set forth in this section.

b. Termination for Cause. Either party may terminate this Agreement for cause upon thirty (30) days written notice in the event the other party breaches a material provision of this Agreement, which breach is not cured within such thirty (30) day period.

c. Effect of Termination. Upon any termination of this Agreement, your right to use the Software terminates. Notwithstanding the foregoing, the following provisions of this Agreement survive any termination: section 5, “Limitation on Your Use;” section 10, “Proprietary Rights;” section 12, “Exclusion of Warranties;” section 13, “Indemnification”; section 14, “Limitation of Liability;” section 16, “General Terms”.

12. EXCLUSION OF WARRANTIES. THE SOFTWARE IS MADE AVAILABLE “AS IS, AS AVAILABLE.” WE EXPRESSLY DISCLAIM ALL WARRANTIES OF ANY KIND RELATING TO THE SOFTWARE, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. WE DO NOT PROMISE THAT YOUR USE OF THE SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE. YOU ALONE SHALL BEAR THE RISK AND YOU SHALL BE SOLELY RESPONSIBLE FOR ANY DAMAGE TO YOUR COMPUTER SYSTEM OR OTHER DEVICE OR LOSS OF DATA THAT RESULTS FROM YOUR USE OF THE SOFTWARE. WE EXPRESSLY DISCLAIM ANY WARRANTIES THAT MAY BE IMPLIED OR OTHERWISE ARISE FROM USAGE OF TRADE OR COURSE OF DEALING, OUR COURSE OF PERFORMANCE. NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED BY YOU FROM US SHALL CREATE ANY WARRANTY NOT EXPRESSLY STATED IN THIS AGREEMENT.

13. INDEMNIFICATION.

a. By Absio. We shall indemnify, hold harmless and defend you, and your shareholders, directors, officers, employees, agents and/or representatives, from and against any and all actions, disputes, proceedings, claims, damages, expenses, liabilities, losses and costs, including reasonable attorney fees, arising from or relating to any claim that the Software infringes or misappropriates any United States intellectual property right. We will have no obligations under this section for any claim that results from: (i) any modification, alteration or change to the Software by you or by a third party on your behalf without our written consent; (ii) your use of the Software in a manner not authorized by this Agreement, or otherwise in writing by us; (iii) the unlicensed or unauthorized use or distribution by you of the Software; (iv) use of a superseded or altered release of the Software if infringement would have been avoided by the use of a current unaltered release of the Software that we provide you at our expense; or (v) any combination of the foregoing.

b. By You. You agree to indemnify, hold harmless and defend us, and our shareholders, directors, officers, employees, agents and/or representatives, from and against any and all actions, disputes, proceedings, claims, damages, expenses, liabilities, losses and costs, including reasonable attorney fees, arising from or relating to any use of the Software by you or your Customers in violation of this Agreement, or any third party claims made against us based upon use of the Software by you or your Customers.

c. General Indemnification Terms. The indemnifying party will defend at its expense any action described in this Indemnification section brought against any indemnified party and will pay any costs and damages finally awarded against the indemnified party in such action or in settlement of such claim; provided that the indemnified party shall not be required to pay any settlement to which it has not consented, which consent shall not be unreasonably withheld. As a condition to receiving any such indemnification, the indemnified party must promptly notify the indemnifying party in writing of such claim and permit the indemnifying party to control the defense of any such claim, which consent shall not be unreasonably withheld. The indemnified party shall have the right, at its own expense, to participate in the defense of any such claim through counsel of its own choosing. The indemnified party shall cooperate reasonably, at the indemnified party’s expense, with the indemnifying party in defense of such claim.

14. LIMITATION OF LIABILITY. EXCEPT FOR OUR INFRINGEMENT OBLIGATIONS HEREUNDER, OUR CUMULATIVE LIABILITY UNDER THIS AGREEMENT WILL NOT EXCEED THE TOTAL AMOUNT OF FEES PAID BY YOU PURSUANT TO ALL PURCHASE ORDERS IN EFFECT WITHIN THE 12-MONTH PERIOD IMMEDIATELY PRECEDING THE ACT GIVING RISE TO THE LIABILITY. IN NO EVENT WILL WE BE LIABLE FOR DIRECT, INCIDENTAL, SPECIAL, PUNITIVE, EXEMPLARY, OR CONSEQUENTIAL DAMAGES, INCLUDING LOSS OF PROFITS, REVENUES, DATA, USE, ANY OTHER ECONOMIC ADVANTAGE OR COST OF COVER INCURRED BY YOU OR ANY CUSTOMER ARISING OUT OF THIS AGREEMENT, UNDER ANY THEORY OF LIABILITY, WHETHER IN AN ACTION IN CONTRACT, STRICT LIABILITY, TORT (INCLUDING NEGLIGENCE) OR OTHER LEGAL OR EQUITABLE THEORY, EVEN IF WE KNEW OR SHOULD HAVE KNOWN OF THE POSSIBILITY OF SUCH DAMAGES.

15. ACKNOWLEDGEMENT OF ALLOCATION OF RISK. The Software provided to you hereunder is to be incorporated by you into Applications over which we have no control, provided to Customers we have no right to evaluate, and with whom we have no right to communicate or negotiate. You, and not we, therefore, have essential control over circumstances that will enable you to assess and mitigate risk associated with the use of the Software. The provisions of this Agreement are designed to allocate risk consistent with these realities. You accordingly acknowledge that you understand that an essential purpose of the exclusion of warranties, the indemnification and limitation of liability provided in this Agreement is allocation of risks between both of us, which allocation of risks is reflected in the applicable fees and other arrangements between both of us in the Agreement, and that we would not be willing to enter into this Agreement with you and license the Software to you if we were required to bear any additional risk.

16. GENERAL TERMS.

a. Waiver, Amendment or Modification. The waiver, amendment or modification of any provision of this Agreement or any right, power or remedy hereunder shall not be effective unless in writing and signed by authorized representatives of the parties. The terms of this Agreement may not be amended or changed by the terms of any purchase order, service order, acknowledgment, invoice or similar document even though a party may have signed or accepted such document. No failure or delay by either party in exercising any right, power or remedy with respect to any of the provisions of this Agreement shall operate as a waiver thereof.

b. Severability. In the event that any provision of this Agreement is found by an arbitrator or court of competent jurisdiction to be invalid, void or unenforceable, the parties agree that unless it materially affects the entire intent and purpose of the Agreement, the invalidity, voidness, or unenforceability shall affect neither the validity of this Agreement nor the remaining provisions herein, and the provision in question shall be deemed to be replaced with a valid and enforceable provision most closely reflecting the intent and purpose of the original provision.

c. Notices. Any notice or other communication required or permitted hereunder shall be in writing. Notice shall be deemed given on the date of receipt - as evidenced in the case of electronic or written delivery confirmation. Notices to each party shall be sent to the address set forth for each party on the most recent Purchase Order, or to such other place as such party may designate by written notice to the other party.

d. Limitations, Governing Law, Forum Selection. Any claim for breach of contract, negligence, or other alleged wrongful act arising out of this Agreement must be commenced not later than one (1) year after the alleged breach, negligent act, or other wrongful act. The validity, construction and performance of this Agreement shall be governed by and construed in accordance with the United States federal common law. The sole and exclusive jurisdiction for the resolution of any dispute or claim arising out of or under this Agreement shall be the United States federal courts, and the parties expressly consent to the personal jurisdiction and venue in those courts located in Denver, Colorado for this purpose.

e. Relationship. Nothing herein shall be construed as creating a partnership, employment relationship, or agency relationship between the parties, or as authorizing either party to act as agent for the other. Each party shall maintain its separate identity.

f. Entire Agreement. This Agreement, including any Purchase Orders, constitutes the final and exclusive statement of the terms of the agreement between the parties concerning its subject matter, and supersedes any and all prior or contemporaneous oral or written agreements, proposals, representations, statements, understandings between the parties concerning its subject matter. The parties expressly state that no information or materials aside from the terms specifically stated in this Agreement, including without limitation, advertising and marketing materials, statements and representations of salespeople or other individuals, form or are otherwise a part of the basis of the parties’ bargain.

g. Other Remedies. Any and all rights and remedies of a party upon the other party’s breach of or default under this Agreement (whether expressly conferred by this Agreement or otherwise) will be deemed cumulative with and not exclusive of any other right or remedy conferred by this Agreement, and the exercise of any one remedy will not preclude the exercise of any other.

h. Binding Upon Successors, Permitted Assigns. This Agreement will be binding upon, and inure to the benefit of, the permitted successors-in-interest or assigns of a party hereto, subject to the restrictions set forth in section 5(c) herein.

i. No Third-Party Beneficiary. This Agreement is made and entered into for the sole protection and benefit of the parties hereto and is not intended to convey any rights or benefits to any third party, nor will this Agreement be interpreted to convey any rights or benefits to any person except the parties hereto.

j. Verification, Audit Rights. At our request, you shall promptly furnish us with written certification verifying that the Software is being used in accordance with this Agreement, including, if applicable, the number of your developers, the number of Installed Instances, the number of Applications being built with the Software, and the number of Customers for whom you may be building custom/bespoke Applications. You shall give us reasonable access to your books, records and systems solely to verify that the Software is being used pursuant to this Agreement.