This paper is intended for all audiences who might have an interest in overall DotNetNuke installation security, and is designed to assist management in identifying an appropriate level of authentication-related risk.

• Download the Multi-Factor Authentication in DotNetNuke Whitepaper
• Learn more about the Multi-Factor Authentication Provider
• Learn more about the DotNetNuke Web Application Framework

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.

Project Goals

• 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
• 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:

A screenshot demonstrating Amazon S3 cloud-based integration on the DotNetNuke platform

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 Demonstration Displaying URI Selection

Discussion

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.”

File-based ACLs

DotNetNuke does not support file-based ACLs, but these are allowed and enforced by the Amazon S3 service.

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.

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.

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.

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.

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.

B

Among the many improvements present in DotNetNuke version 5.1, this latest release includes authorization as a first-class extension point.  This allows customization previously impossible without core modification.  Additionally, the permission model (and the internal use thereof) has been significantly streamlined and centralized, allowing for great flexibility across myriad use scenarios.

In this session, we explore the new permission provider in detail.  This includes a discussion of how (and why) authorization services were centralized and abstracted, the overall design and structure of the provider, and available points of access control.  Finally, we examine some concrete ways in which the provider might be extended to meet real-world policy requirements.

When presenting architectural or theoretical material, I always strive to include a demonstration of how the material might be applied to a real-world scenario.  In this case, I will be demonstrating how a custom authorization provider can be used to enable full DotNetNuke integration with cloud-based Amazon S3 webservices.  A screenshot of the file manager in an Amazon S3-enabled installation is displayed below.

This session should appeal to a wide audience; I cover enough theoretical background for individuals new to security theory, and delve deep enough into the 5.1 authorization architecture to satisfy those that have high familiarity with the platform.  If you are interested in learning more about the internals of the framework — and how 5.1 authorization might be utilized — be sure to stop by!

Epilogue: The presentation materials are now available here, and the Amazon S3 Integration providers may be found here.