This project is read-only.

DNN Amazon S3 Folder Integration Providers

More details about this project may be found on my blog.


A set of providers (data and authorization) that provide Amazon S3 folder services to a DotNetNuke installation in an integrated and seamless manner.


  • Integration with the Amazon S3 for data storage external to the DotNetNuke framework.
  • Seamless integration into the DotNetNuke UI, both at the File Manager and URL controls. For example:
    • Amazon S3 objects should appear in the File Manager just like any other internal files,
    • Amazon S3 objects should appear in the core URL control, and
    • Insofar as is feasible, Amazon S3 files should be indistinguishable from their secured storage counterparts.
  • No external Amazon S3 UI or kludgy link generation
  • Whenever possible, utilization of 301 Redirects to Amazon S3 resource URIs.
  • Full observance of the external Amazon S3 bucket ACLs.
  • Require no core changes and utilize only existing DotNetNuke extension points


The DotNetNuke content management system is a mature, robust, and widely-adopted web application framework. It offers multiple file persistence options out-of-the-box, including file-system storage (both unsecured and secured by ACL), along with ACL-secured database storage. When creating a link to a resource, the DotNetNuke UI provides a convenient list of these files, and also allows direct input of arbitrary URI.

However, there exists no ready method by which an administrator might link to a known set of files persisted external to the installation. While direct URI input might be used here, it requires knowledge of these data, and does not allow for enumeration and management of the external objects themselves.

This project attempts to bridge that gap by integrating resources persisted on the Amazon S3 into the DotNetNuke framework. Resources stored there are enumerable via the File Manager and selectable via the URL control. Throughout the core framework, these external resources are treated identically to database-secured resources, including observance of Amazon S3 ACL, automatic synchronization, and (reasonably friendly) 301 Redirects to the Amazon S3 when accessed via LinkClick.aspx.

This is effectuated via customization of two providers: authorization and data. The authorization provider integrates Amazon S3 ACLs for external resources, and the data provider allows enumeration of and details about the external resources themselves.

Installation instructions

This provider is installed just as any other module or provider through the Host->Extensions menu option. Note that the provider requires DotNetNuke version 5.1 or greater; ensure that your installation meets this minimum requirement before proceeding.

To install:

  1. Log in as a host user
  2. Install the AmazonS3Providers install package, and
  3. Add an Amazon S3 key and secret to the administrator profile for any portal that requires access to Amazon S3 storage (the profile keys are created automatically).

Configuration and Usage

After installation, two new profile properties will be automatically created across all portals:
  • S3Key, and
  • S3Secret

The names of these properties may be changed in the web.config near the configuration/dotnetnuke/permissions node). To enable a portal for Amazon S3 integration, the key and secret for the portal administrator must be configured with valid values.

Any user may submit his or her own key and secret information at the profile level; these data will be used to circumscribe the set of available Amazon S3 objects for that user.

After a portal's administrator account is configured with a valid Amazon S3 key and secret, the file manager will display those buckets and objects stored on the service:

Amazon S3 File Manager.png

The list of available buckets will be circumscribed by the permissions granted by the administrator's S3 account. Because DotNetNuke does not support file-level ACLs, objects within an Amazon S3 bucket are assumed to have an ACL identical to that present on the bucket itself (though a more restrictive policy will still be enforced by the S3 service).

Similarly, the DotNetNuke URL control will display a list of buckets accessible by the accessing user, and allow selection of the objects therein:

Amazon S3 URI Teaser.png


  1. Overall Authorization Model. There are a number of areas in which the authorization policy enforced by the provider might be improved. In its current form it is minimally complete, but could easily be made more robust and sensitive to user context (in particular, no attempt is made to deal with Amazon S3 user-specific ACL assignment). The provider is largely aimed at objects intended to be made available to "everyone."
  2. File-based ACLs. DotNetNuke does not support file-based ACLs, but these are allowed and enforced by the Amazon S3 service.
  3. Generated URIs. The 301 redirect URIs created by the data provider are not per-user, and thereby require read-permission on the "everyone" group for the S3 object in question. A stronger model might generate a valid read URI for the accessing user, so long as that user has read permissions on the object itself.
  4. CRUD. Only read access is implemented for Amazon S3 buckets and objects; while it remains quite straightforward to implement the other access characteristics, these are left to the (many) other S3 managers that exist for these purposes.
  5. Shared secret storage. Shared secrets are stored in plain-text on a user's profile; this is generally a horrible security policy. Because federated authentication is not possible with the Amazon S3 service, this secret cannot be made application-specific and must be stored somewhere.
  6. Performance. A number of internal operations are O(n*m). While some of these are cached by the underlying DotNetNuke framework, the integration implementation itself could be improved via additional caching and lookup tables.

LitS3 Service Interoperability Library

This extension leverages the LitS3 library for communication with the Amazon S3 service.

Help! My Installation Exploded!

In the unexpected event that either of the two providers (data and authentication) fail -- either during initial installation or subsequent usage -- automated uninstallation may not be possible. This is because the installation package replaces one of the fundamental underlying components of the DotNetNuke framework -- data persistence.

Note that if no access-preventing failure occurs, the normal DotNetNuke extension uninstallation procedure will automatically perform the work outlined in this section. No manual intervention is necessary in this case.

Should an installation fail as a result of this enhancement, manual removal of the provider metadata may be necessary. Instructions for this procedure are outlined here.

Feedback, Reviews, and Ratings Appreciated!

Feedback about your experiences is needed, and greatly appreciated!

Last edited Apr 23, 2014 at 9:03 PM by BrandonHaynes, version 13