Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Manage Custom Security Credentials the Smart (Client) Way

By default, you can only manage the security credentials of the SQL Server database that ships with ASP.NET 2.0 using a local instance of Visual Studio 2005. This article shows how to extend the management capabilities by wrapping the ASP.NET 2.0 providers with a Web service and using a Windows Forms application to manage the credentials store.


advertisement
oth Internet and intranet applications often require a custom store for user accounts and roles. ASP.NET 2.0 provides an out-of-the-box provider model as well as a SQL Sever database just for that propose. Unfortunately, the only way to administer the credentials databases is via Visual Studio 2005, and only for local Web applications. This article presents a full-blown custom security management application that administrators can use. The application wraps the ASP.NET 2.0 providers with a Web service and even adds missing features. This article presents the design approaches, challenges, and techniques involved in developing such an application. The article also walks you through some powerful yet useful techniques such as interface-based Web services, reflection-based Web service compatibility, advanced C# 2.0, Web services security, and Web services transactions.

ASP.NET 2.0 Credentials Infrastructure
Internet-based applications often don't rely on Windows accounts and groups, and instead resort to form-based authentication, combined with some kind of a back-end custom credentials store such as SQL Server. To save developers the trouble of designing and building such solutions over and over, ASP.NET 2.0 ships with a ready-made security credentials infrastructure. The ASP.NET 2.0 credentials store is not just for the sole use of ASP.NET applications: ASP.NET Web services and even Windows Forms applications can use it to manage their user's credentials. In addition, Windows Communications Foundation (codename Indigo) services can also be easily configured to use the ASP.NET 2.0 security credentials store.

ASP.NET 2.0 uses a provider model for accessing and managing the credentials to avoid coupling the application to any particular store. It is up to the developers to develop the application while taking advantage of the abstract provider model. It is up to administrators to select and manage the specific credentials store. Figure 1 shows the architecture of the ASP.NET 2.0 security providers. Membership providers are responsible for managing users, and role providers are responsible for managing roles. In the credentials store, each user or role is scoped inside an application. This allows different applications to use the same credentials store without conflicting with each other's user names or roles. Out of the box, ASP.NET offers support for the following credentials stores: SQL Server, Windows, and Active Directory (see Figure 1). To install the SQL Server credentials database, run the aspnet_regsql.exe setup program, found under:

 
Figure 1. The ASP.NET 2.0 Security Provider Model. ASP.NET offers out-of-the-box support for several credentials stores.

<WINDOWS>\Microsoft.NET\Framework\<version>


The setup program creates a new database called aspnetdb, a set of tables for applications, users and roles, and stored procedures to access the tables. The SQL Server database is well designed, using the latest security best practices such as password salting and challenges. In addition, ASP.NET 2.0 offers a set of classes that correspond to the providers in Figure 1.

Which provider to use is kept in the application's configuration file (App.Config or Web.Config). You hardly ever need to interact with the specific providers directly. Instead, there are two static helper classes, Membership and Roles, which read from the configuration file which provider to use. The default provider, that is, when no provider is specified, is SQL Server. The Membership class (see Listing 1) allows you to create and delete users, retrieve information about users, and review the password policies. For example, to create a new user in the "MyApp" application you would simply write:

ASP.NET 2.0 ships with a ready-made security credentials infrastructure.

Membership.ApplicationName = "MyApp"; Membership.CreateUser("MyUser","MyPassword",...);


The Roles class allows you to create and delete roles, add or remove users from roles, retrieve users' role membership information, and verify role membership. Here's the class definition:



public static class Roles { public static string ApplicationName{get;set;} public static void CreateRole(string roleName); public static bool DeleteRole(string roleName, bool throwOnPopulatedRole); public static void AddUserToRole(string username, string roleName); public static void RemoveUserFromRole( string username, string roleName); public static string[] GetAllRoles(); public static string[] GetRolesForUser( string username); public static string[] GetUsersInRole( string roleName); public static bool IsUserInRole(string username, string roleName); //Additional members }


For example, to add the role "Manager" to the application "MyApp" you would write:

Roles.ApplicationName = "MyApp"; Roles.CreateRole("Manager");


Administering the Credentials Stores
If you choose either Windows or Active Directory to store your application's users and roles, then you need to administer the user credentials using the dedicated tools for those stores, such as the Computer Management control panel applet or Active Directory tools. The real question is how to administer the credentials stored in SQL Server. To that end, you can use Visual Studio 2005 and a Web browser even if you don't have IIS installed. In an ASP.NET Web project, select ASP.NET Configuration from the Website menu. This will make Visual Studio host a Web server, open an available port, and navigate to a set of administration pages (see Figure 2). The administration pages modify the Web application configuration file and may also manage the credentials store (when Windows authentication is not selected). When using Visual Studio 2005, you first need to select the authentication type. You can choose between Windows or Forms authentication (Internet access). If you choose forms authentication, you can also perform the following operations:

 
Figure 2. Administration Pages: The ASP.NET Web application administration pages.
  • Enable or disable role-based security
  • Create and delete roles
  • Create and delete users
  • Retrieve a user's details
  • Set a user's status
  • Assign users to roles
  • Remove users from roles
Since SQL Server is the only Enterprise-worthy custom credentials store offered by ASP.NET 2.0, you are likely to use the Visual Studio 2005-driven administration pages solely for managing the aspnetdb database, rather than any other store.

Shortcomings of the Built-In Offering
There are a number of significant shortcomings to the Visual Studio 2005-driven administration pages: First, you need Visual Studio 2005. It is unlikely that application or system administrators will have Visual Studio 2005, let alone know how to use it. The administration pages use a slash (/) by default for the application name, and do not offer any way to modify that. There is no remote access: the application and Visual Studio 2005 must be co-located so that Visual Studio 2005 can access the application's configuration file. The browser-based user interface is somewhat annoying, and you need to frequently click the Back button, and the user interface is rather dull. Many features that administrators are likely to want to use are not available via the administration pages. This is in spite of the fact that the features are supported by the underlying provider classes. Some of the things missing from the Visual Studio 2005-driven administration pages include:

It is unlikely that application or system administrators will have Visual Studio 2005, let alone know how to use it.
  • ability to update most if not all of the details in a user account
  • retrieve a user's password
  • change a user's password
  • reset a user's password
  • retrieve information about the number of current on-line users
  • ability to remove all users from a role in one operation
  • retrieve information about the password management policy (such as length, reset policy, type of passwords, etc)
  • ability to test user credentials
  • ability to verify user role membership
Moreover, there are additional features that administrators are likely to want, and yet they are not supported, not even by the provider classes. These features include the ability to retrieve a list of all of the applications in the database, the ability to remove all users from an application, the ability to remove all roles from an application, the ability to delete an application (and all its associated users and roles), and the ability to delete all applications.

 
Figure 3. The Credentials Manager Application: Here's a screenshot of the application.
In conclusion, while ASP.NET 2.0 offers a first-class, comprehensive credentials store (sans a few desired features), it only offers a rudimentary administration option, one that is unlikely to be used by actual administrators.

This disparity motivated me to develop the Credentials Manager application—a smart client application that compensates for all the shortcomings just listed. Figure 3 shows a screenshot of Credentials Manager. The rest of this article explains how I designed and built Credentials Manager.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap