I am pleased to announce a beta release of my Amazon S3 integration authorization and data providers. It may be downloaded via CodePlex on its project homepage. As is all of my DotNetNuke work, this project is fully open-source and available under a liberal BSD license.
The DotNetNuke web application framework 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.
- 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
Configuration and Usage
After installation, two new profile properties will be automatically created across all portals:
- S3Key, and
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:
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:
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.”
DotNetNuke does not support file-based ACLs, but these are allowed and enforced by the Amazon S3 service.
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.
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.
Shared secret storage
Shared secrets are stored in plain-text on a user’s profile; this is generally a horrible security policy (Alex Shirley will certainly yell at me for doing this after I strongly discouraged him from doing so in a similar project). Because federated authentication is not possible with the Amazon S3 service, this secret cannot be made application-specific and must be stored somewhere. The solution here is an encrypted profile property type; this is clearly outside the scope of this project, but is on my radar for a future complimentary project.
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.
Your Feedback is Needed!
As this project moves toward an initial production release, it will rely heavily on the feedback provided by the community. Any such feedback — including comments, ratings, and constructive criticism — is greatly appreciated.
The Beta Release: DotNetNuke Amazon S3 Folder Integration Providers by Brandon Haynes, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.