~
Archive for DotNetNuke (DNN) Content Management System ~

I am pleased to announce a beta release of my cross-portal symbolic link folder provider. 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 content management system is designed with multi-tenancy in mind, and allows an arbitrary number of websites (“portals”) to be created therein. These portals may be configured at the root of a given domain (e.g., “http://dotnetnuke.com”) or as a child portal below the root of a portal hierarchy (e.g., “http://dotnetnuke.com/mychildportal”). Historically these child portals have had no structural link to their parent counterpart, other than sharing a similar base URI.

This provider is designed to expose the file system in a parent portal to all child portals via specially-formed symbolic links. This allows administrators of child portals to access and utilize these files in a natural manner via existing dialogs and other DotNetNuke services. It creates an implicit linking between these two portal entities, and in configurations where there is significant overlap in data usage between parent in child portal (for example, when a child portal represents a single department within a larger corporate environment) allows for greatly simplified administration. (more…)

Second Harvest: Built on DotNetNuke

Equally important for many readers of this blog, this Second Harvest organization utilizes DotNetNuke as a platform for donations, food drives, and in communicating its important mission. It is especially fulfilling for me personally to be a part of an open-source platform that is utilized to help those in need, and I am confident that anyone who has ever contributed to or supported the DotNetNuke ecosystem in any way feels the same.

Second Harvest of Santa Clara and San Mateo Counties is a fantastic example of a great charitable model combined with some excellent technology choices. Any charity that is able to return 95% of its contributions to those it is trying to help easily meets this bar, and Second Harvest leverages DotNetNuke to accept donations in a meaningful way from contributors around the country.

Nothing else matters when you’re hungry. Give a gift that matters at this critical time. If your cupboards are full, please help others who don’t know where their next meal will come from. No donation is too small; giving as little as $10 is enough to provide 20 people with the most basic human need: food.

This is a great opportunity to ensure that children, families, and seniors don’t go hungry.

Please join us in this effort to assist the less fortunate who have to decide between paying for rent, utilities, or medicine and providing food for their loved ones.

After lingering in limbo for some time, I am pleased to be able to provide some screenshots of my upcoming DotNetNuke Module Container project. This project is expected to be released into beta sometime in mid-November, though I may circulate to a few interested parties before any public release.

The project is designed to address a common usability concern with the default DotNetNuke control panel, which is perhaps best illustrated pictorially:

A Scary DotNetNuke Menu with Many, Many Options

As users of the framework have surely noted, the list of modules available to an administrator is lengthy and highly-confounding. While experience mitigates this difficulty, it remains a significant challenge for new administrators to understand which module to select from this imposing list.

This project attempts to group this set of modules into manageable containers where each module is grouped by function (e.g. administrative modules, e-commerce modules). By way of example, a clean DotNetNuke 5.1.4 install with ALL core modules installed (and grouped into logical containers) would be reduced to a very understandable list:

A compact, minimized DotNetNuke control panel module list with groups by function. Note that the image above continues to utilize the default DotNetNuke control panel; the containers do not require any adjustment to that component.

After a container is selected and instantiated, a user is prompted to select from one of the modules contained therein:

Interactive selection of a module within a grouping after selecting the group from the control panel.

The Entity Framework ObjectContext allows for development using a model automatically generated by a Visual Studio designer. However, when deployed within DotNetNuke, these attributes do not pick up the database owner and object qualifier required for correct inter-operation. Because of this, large-scale deployment of modules using the Entity Framework is infeasible, and modules using the technology are unfortunately limited to internal applications.

To remedy this issue, I have developed an adapter that converts the Entity Framework model generated by the designer into a DotNetNuke-compatible model that uses both the object qualifier and database owner specified by an end-installation. This adapter is based off of the more generalized model adaptation framework that I recently released.

My goals for any satisfactory solution were as follows:

Run-time adjustment of an Entity Framework EDMX model to conform to any given DotNetNuke installation, including:

Connection-based adaptation (e.g. use of a runtime-specified connection string)

Adjusting the owner of database objects to match the DotNetNuke installation DatabaseOwner

Continued use of the Visual Studio Model designer

No tedious changes in the compiler-generated code

Continued use of an assembly-embedded EDMX model (and thereby no additional or external schema deployment files)

This solution extends the Entity Framework runtime model adapter to operate within a DotNetNuke extension, allowing a developer to design against an unqualified, dbo-owned DotNetNuke instance and be assured that it will deploy (and operate) correctly on any configuration that an end user might have deployed. Adaptation is largely inexpensive, and since the models are cached by type, performance is not significantly affected.

Click here to access the project site for additional details and downloads. Though the content herein is protected under the license below, be sure to consult the project license (New BSD) for integration-related details.

I am pleased to make available a whitepaper detailing the high-level motivation and approach involved in the creation of the recently-released DotNetNuke Multi-Factor Authentication Provider, along with a discussion of the unique characteristics of a DotNetNuke installation that render the approaches of other vendors (e.g. RSA SecurID) incomplete or unsatisfactory. Additionally, each out-of-the-box factor is described in general detail in a format that is digestible by an audience of varying technical sophistication.

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.

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.

However, subsequent to my original posting detailing this approach, I experienced some IPR issues that required my removing the download links to the actual assembly and source code. While the information in the entry itself was largely sufficient to recreate this adapter, it required a reasonably significant amount of expertise to do so. As a result, I suspect that many were unable to utilize the material therein.

I am pleased to announce that I have reached resolution on the relevant IPR issues that precluded my releasing the associated code, and have re-enabled the download links in the original post. For convenience, I am also including them below.

I recently had the privilege of presenting at the DoDNN conference on the topic of authorization theory and the new extension points available in DotNetNuke version 5.1. This was an enjoyable session with great attendees and some interesting conversation afterwards.(more…)

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!