Extending ASP.NET 2.0 Membership
This article explains some of the basics about “Membership” in ASP.NET 2.0 and how to extend the ASP.NET 2.0 security model
Extending the Membership Role Provider
Membership
The ASP.NET 2.0 membership role provider (from the SQL Server side) is a collection of MS SQL tables, stored procedures, and views called SqlMembershipProvider. This provider uses a database named aspnetdb and can be installed on your SQL server by running the SQL Server script found in the .net directory of Visual Studio install.
The following quote from Microsoft MSDN found at http://msdn2.microsoft.com/en- us/library/system.web.security.sqlmembershipprovider.aspx will help.
“To manually create the database, run the Aspnet_regsql.exe executable found in the %systemroot%\Microsoft.NET\Framework\ versionNumber folder and specify the -A m option (for example aspnet_regsql.exe -A m). The database created is called Aspnetdb. Alternatively, run Aspnet_regsql.exe to pull up the GUI configuration mode and choose to configure all ASP.NET Features.”
The SQL Database side (SqlMembershipProvider) also includes SqlRoleProvider and SqlProfileProvider. The SQL side, together with the (application side) System.Security and System.Web.Security namespaces makes up the bulk of the Membership Role Provider security features in ASP.NET 2.0. As a side note the “Profile” ASP.Net objects are for tracking user options and personalization’s, such as web parts and user web page preferences.
Configuring Your Application
Visual studio allows you to configure the database for your ASP.NET application in both Visual Studio 2005 and Visual Studio 2008 by referencing the Website Menu and clicking ASP.NET Configuration. However in a production deployment configuration, deploying the application this way is not optimal and you are better served to have your DBA configure the application settings for your ASP.NET 2.0 application when using the SQL Membership Role Provider.
Security Namespace
System.Web.Security.Membership
This model allows both roles and users in roles to access various parts of an ASP.NET 2.0 application. Generally, you can set a web.config file for each ASP.NET directory if desired. An example below assumes you have configured the SQL Membership role provider to contain two roles, GeneralUsers and Administrators.
<configuration>
<system.web>
<authorization>
<allow roles="GeneralUsers" />
<allow roles="Administrators" />
<deny users="*" />
authorization>
system.web>
configuration>
Note: Forms based authentication in ASP.NET can be configured to use the SQL Membership provider or without. I note this because forms based authentication is independent of the SQL Membership Provider.
Users and Roles
The below C# example show you how to get a user.
String strUserName;
strUserName = HttpContext.Current.User.Identity.Name;
Object UserID;
try
{
UserID = Membership.GetUser(strUserName).ProviderUserKey;
}
catch
{
UserID = Membership.GetUser("Anonymous").ProviderUserKey;
}
In the example above we are checking for a valid user and if not found assume that we have an anonymous user where “Anonymous” is an actual user name that appears in the SQL membership user table as a user. Meaning, we have a user id purposefully setup to be the catchall. In this example if we did not actually setup a catchall user account we would get a membership provider error. Also note, that once we have the user we can find out what roles the user is part of.
To summarize, the membership role provider gives you the following
· Roles
· Users In Roles
· Users, independent of roles
Membership Role Provider Limitations
System.Web.Security.Membership is limited and may not meet the requirements of larger businesses that need more depth to security in ASP.NET 2.0. For example, what if you have a large pool of administrators where some or all administrators need to do different things with different rights? In the model described above anyone who is an administrator is allowed the same rights. The workaround with this model is to create several duplicate directories each with a custom web.config file. This is not practical especially if the pool(s) of Administrators is large and changes frequently.
Extending the Model
This model can easily be extended by creating a collections based group structure. What does this mean? Consider the following;
Imagine two separate groups of people standing around and each group has an object or collections of objects in their possession. Group A wants to share an object collection with Group B, but only, wants to share with administrators in group B. Further, Group A is willing to let select users who are not administrators access only one or two objects that Administrators from Group B will have access to.
Extending this model is as simple as creating two tables and adding extra user fields to object or object collections tables.
CREATE TABLE [dbo].[tblUserGroups](
[UserID] [uniqueidentifier] NOT NULL,
[Groups] [char](255)
CREATE TABLE [dbo].[tblGroups](
[GroupID] [uniqueidentifier] NOT NULL,
[GroupName] [char](100)
[GroupDescription] [char](255)
[GroupNumber] [int] IDENTITY(1,1) NOT NULL
Essentially, you are adding a “UserGroups ” field to a collection table which is parent to and contains object items. As an example consider, a photo album as a collection and individual photo objects in the collection. In this case, you would add a “UserGroups ” field to the your “Album” table.
Security on this collection is now enhanced and together with the Membership Role Provider you get
· Restrict / Allow accesses to ASP.NET web directories via web.config files
· Assign User to Roles
· Assign Groups to Users
· Assign Groups to a collection
· Ability to use ASP.NET built in “Forms Authentication”
This doesn’t sound like much but consider the following:
A user must be a member of the role, a member of a group, and the group that the user is a member of must also have access to the collection, and the (role / user) must have access to the ASP.NET directory.
With this model, you can now create groups of administrators with different accesses to collections and different directories. Users in those groups are restricted based on which administrator group and directory they have access to. You can also do the same thing for non-admin groups.
In this scenario it’s also possible that a user may have access to an object collection but the collection is presented through a restricted directory which does not allow the user to see the collection. In this case the user may see the object collection from other ASP.NET directories for which the user has access.
Basic Security Flow
· User Logs In
· Application checks to see which roles the user is a member of
· User is presented with only menus and directories for which the user has rights
· User requests to see an object collection or object within a collection
o Application checks which groups are assigned to the object collection
o Application checks which users are assigned to the collection via user group
Further Extending the Model
Technically, you could extend this model down to each item in the object collection. However, making a new collection with only the items needed makes more sense. Consider our Group A and Group B photo album example above. It doesn’t make sense for one group to remove photos from a photo album before allowing the other group to view the collection. More likely, a new photo album would be created with only photos viewable by the other group. Managing collections is easier than trying to keep track of individual objects.
Implementing the Extended Model
In this extended model there is not a direct user assignment to objects or object collections. Objects are part of object collections and collections are assigned to groups. Users are assigned to groups which may be different than groups assigned to the collection. Meaning, object collections are assigned to groups independently of user assignment to groups.
To implement this model you would need to build into your database or application, a comparison mechanism that compares the groups assigned to the collection with the groups assigned to the user. If a user and collection have matching groups then the user is permitted to see the collection.
If you ASP.Net application were to allow direct access to objects within collections you would also need a mechanism for finding the group, collection, and role for the requested object before presenting the object to the requestor.
Conclusion
The SQL Membership Provider (aspnetdb) and the ASP.NET System.Web.Security.Membership make easy work of implementing a flat security model. Extending, and adding depth to this model is easy and with a few simple fields you can create a dynamic and robust security model. I think extending an existing model makes more sense than writing a security model from scratch. Ultimately, the security demands of your application will determine if you can simply extend an existing model or use a different security mechanism.
References
http://msdn2.microsoft.com/en-us/library/yh26yfzy.aspx
http://msdn2.microsoft.com/en-us/library/system.web.security.sqlmembershipprovider.aspx