DotNetNuke Membership Overview

Security in ASP.NET 2.0

In ASP.NET 1.x, the native authentication and authorization services relied on external data stores or configuration in the web.config file. For example, in ASP.NET 1.1 an application can provide formsbased authentication. This requires the developer to create a login form and associated controls to acquire, validate, and manage user credentials. After authentication, authorization is provided through XML configurations in the web.config file.

In ASP.NET 2.0, several new security enhancements expand on these services in three distinct ways:

• Login and user controls: A new suite of login and user-management controls reduce the need to rewrite standard user code for each application. You can, for example, create a set of pages for registering a new user, allowing an existing user to log in, and sending a forgotten password to a user simply by placing the appropriate controls on the page and setting a few properties.

• User management: Each ASP.NET 2.0 application can be accessed through a special set of administrative pages, which enable an authorized user to create new users, assign users to roles, and store user information. If you want to write your own management tools, you can access all of the same features programmatically. Note that the ASP.NET Web Configuration can only be run in a development, non-production environment, meaning the developer has to create his own solution for the production environment.

• Membership/Roles Provider: The membership feature creates a link between the front-end features (login controls and user-management site) and the persistence mechanism. A Membership provider encapsulates all the data access code that is required to store and retrieve users and roles. Thanks to the Provider Model, this component can easily be replaced with a provider that supports your particular data source.

Together these three components reduce the amount of code that is required to provide authentication and authorization services and persist the data to a data store. In designing these classes, Microsoft understood that it could not account for all possible use cases. Realizing this, Microsoft implemented them by using a Provider Model design pattern — the same one DotNetNuke uses in its own architecture throughout the application, as discussed in Chapter 7.

In the Member Role backported version, only the Membership/Roles Provider described earlier was actually backported to the 1.1 framework. This was not an issue for DotNetNuke because it already had its own login and user controls as well as its own user-management interface. Because the controls existed, all that was left to do was to modify the controls to use the API exposed by the Membership Provider.

The Membership/Roles Provider can actually be divided into the three distinct services outlined in Table 9-1. As a group, they are referred to as Membership Provider Services. Notice that all these default concrete providers use Microsoft SQL Server or SQL Server Express as their data store.

Table 9-1: ASP.NET 2.0 Membership Services Default Providers

Service	Default Concrete Provider Namespace
Membership	System.Web.Security.SqlMembershipProvider
Role Management	System.Web.Security.SqlRoleProvider
Profile	System.Web.Profile.SqlProfileProvider

The Profile service hasn't been mentioned until now because it is not part of the System.Web.Security namespace. Despite this, it was part of the Member Role backported version and was utilized in the DotNetNuke implementation. Keep in mind that it is possible to implement your own concrete providers using a different data store if you so desire.

With the basics of ASP.NET 2.0 security and Membership Provider Service in mind, the following section moves on to how DotNetNuke implements these service providers.