Amazon S3 with authorization

When using Remote Storage as for instance with Amazon S3, it might be needed to secure access to the S3 buckets used instead of using ‘public’ access. This means that there will be no anonymous access, but also that the requests to the content in the bucket needs to be authenticated.

There are two ways to do this:

  • use the Authorization header
  • send a signature as a URL-encoded query-string parameter.

The following examples will use the second method.

More information can be found in Amazon’s Authenticating Requests documentation.

AWS Signature v4

New in version 1.7.29.

As of January 30, 2014, newer AWS regions such as eu-central-1 require the use of the AWS Signature v4 for authentication. To enable the use of v4 signatures the name of the S3 region must be set when configuring access to the bucket. If the region is set, v4 signatures will be used whether or not the region requires it. Not setting the S3 region will result in USP using the older v2 sigature method that may not be supported by all regions.

Using webserver directives for S3 authentication

New in version 1.7.2.

It is possible to use webserver directives and let USP sign the request automatically with the following webserver directives.

This covers one specific use case: both content (mp4/ismv) and server manifest (ism) are placed in the S3 bucket and the manifest references the content locally (no paths or URLs, just the filename).

The directives for Apache are the following:

Option Description
S3SecretKey The AWS secret key.
S3AccessKey The AWS access key.
S3Region Region of bucket where data is stored, added in 1.7.29. Required for AWS Signature v4.

The directives for Nginx are the following:

Option Description
s3_secret_key The AWS secret key.
s3_access_key The AWS access key.
s3_region Region of bucket where data is stored, added in 1.7.29. Required for AWS Signature v4.

The keys can be created in the AWS IAM portal and managed there as well (active/inactive, delete).

There is one limitation, the directives need to be placed in a location mapping to the directory that is setup to use IsmProxyPass.

The reason for this lays in Apache’s handle chain where Directory is processed differently from Location so the S3 keywords are not available when placed in Directory.

Apache example

<Location "/s3_auth">
  S3SecretKey SECRET_KEY
  S3AccessKey ACCESS_KEY
  S3Region    BUCKET_REGION
</Location>

<Directory "/var/www/test/s3_auth/auth-remote-manifest/">
  IsmProxyPass http://unified-streaming-auth.s3-eu-west-1.amazonaws.com/
</Directory>

An explanation of the parts of the paths used in Location and Directory:

Path Description
/var/www/test The document root
/s3_auth The location mapping applying the S3 directives
/auth_remote_manifest The directory that maps IsmProxyPass into place

The following curl call will return the client manifest created from the securely fetched server manifest.

curl -v http://test.unified-streaming.com/s3_auth/auth-remote-manifest/oceans.ism/manifest

Playout will follow the same pattern: Apache will translate the request into S3 and apply the signature.

Nginx

With Nginx, a Directory directive in the virtual host is not needed, a location will suffice.

location ^~ /s3_auth/auth-remote-manifest/ {
  s3_secret_key SECRET_KEY;
  s3_access_key ACCESS_KEY;
  s3_region     BUCKET_REGION;
  ism_proxy_pass http://unified-streaming-auth.s3-eu-west-1.amazonaws.com/;
  usp_handle_ism;
}