Integrating a Client or Vendor with Alli Cloud Storage
Introduction
Alli Cloud Storage, based on AWS S3, provides a handful of different options when setting up integrations with clients or vendors. It gives us the capability to share files from Alli, or receive and ingest files from third parties. When we onboard a new client to Alli they are provisioned with their own S3 bucket that can be accessed from anywhere within Alli. S3 has become an industry standard for file storage and transfer, so many tools and vendors support it directly. Because of this, there are a number of options when integrating with clients and the tools or vendors they use.
The following presents some common scenarios for sharing via S3 and what information we need from the client, and what information we should share with them.
When requesting a new integration please open an ASD request with as much information as possible so we can quickly choose the appropriate scenario.
Client/Vendor’s Workflow is in AWS
This is the easiest and most secure scenario and doesn’t require sharing any API keys, only setting up a trusted relationship between our AWS account and theirs. We do this by granting a role or user in their account the ability to access the S3 bucket in our account.
Assumed Role
This gives third parties the ability to assume a role in our AWS account thus giving them access to the client S3 bucket. In order to implement this type of integration we need the following information from the client or their vendor:
AWS Role or User ARN: Following are some examples
CODEarn:aws:iam::1234567890:user/ClientUser-abcd arn:aws:iam::1234567890:role/VendorRole-abcdAn optional External ID: This will be a random alphanumeric string that provides an added layer of security. It is optional, but some vendor tools require it. For example, it could look something like this
CODEid_YjJmODYzMmMtMDhhMy0xMWVmLTg1ZjEtMDM3MmViYjJjNDEyCg==
After we receive the above information we will be able to set up the trust relationship and allow their tools to assume a role in our AWS account which can access the client’s S3 bucket.
Direct Trust
The next option for an AWS-hosted workflow is directly trusting an external entity to write to our S3 bucket. This doesn’t require the intermediate step of assuming another role, so it is sometimes easier for less sophisticated clients or vendors to set up with their available tools. In this case, we only need a user or role ARN like the above assumed role.
Workflow Outside of AWS
In this case, the only straightforward option is to provide the client with an Access Key ID and Secret. Any tool which can communicate with S3 will be able to use these credentials, but we present this option as a last resort because it uses long-lived credentials versus temporary credentials like the solutions above.
Access Key ID and Secret
The only information we need in this case is the client and a vendor or purpose for the integration so we can describe the integration on our end for tracking. For example, if we are doing an Adobe integration for Kohler, we would call this integration kohler_adobe.
Providing Setup Information
Depending on which one of the above solutions is used, we will provide different information back to the client or vendor to complete set up of the integration. In all cases we will provide a bucket name and key prefix which they are permitted to read from and write to. The key prefix can also be known as path, directory, folder, or object prefix.
Assumed Role
For the assumed role scenario, we will provide a role ARN, bucket name, and key prefix.
Direct Trust
When using direct trust, we will provide only a bucket name and key prefix.
Access Key ID and Secret
We will provide an Access Key ID, Secret, bucket name, and key prefix.