Asp.net| secure read feeds by default, you can only use a native instance of Visual Studio 2005 to manage security credentials in a SQL Server database that is published with ASP.net 2.0. This article will show you how to use a Web service to wrap a asp.net 2.0 provider and expand this management capability by using a Windows Form application to manage the voucher store.
Today, both the Internet and intranet programs generally require a customized way to store and manage user accounts and roles. To this end, ASP.net 2.0 provides a ready-made provider model and a SQL sever database. Unfortunately, this credential database can only be managed through visual Studio 2005来 and only for native Web applications. This is no doubt very inconvenient and not widely used.
This article describes a fully customizable security management application that a super user can use. The application wraps and adds functionality to the ASP.net 2.0 provider by using a Web service. This article describes in detail the design approach, the problems faced and the technologies included in the application. It also introduces some useful and powerful technologies, such as web-based Web services, reflective Web service compatibility, Advanced C # 2.0 programming, Web Services security, and Web service transactions.
First, asp.net 2.0 certificate infrastructure
internet-based applications often do not rely on Windows accounts and groups, but rely on form-based authentication and combine some sort of background custom voucher store, such as SQL Server. To help developers avoid duplication of design and build such solutions, a ready-made security credential infrastructure is added to the ASP.net 2.0 release. The ASP.net 2.0 credential store is not only available for asp.net applications, but it can be used by ASP.net Web services and Windows Form applications to manage their user credentials. In addition, the Windows Communication base (encoded as indigo) service can also be easily set up to use the ASP.net 2.0 security voucher store.
ASP.net 2.0 uses a provider model to access and manage credentials to avoid coupling applications to any particular storage. This application is developed by programmers while leveraging the advantages of the abstract provider model. A superuser is responsible for selecting and managing a particular credential store. Figure 1 shows the architecture of the ASP.net 2.0 security provider.
Figure 1. ASP.net 2.0 security provider model
Membership provider is responsible for managing users, while role provider is responsible for managing roles. In the voucher store, each user or role is limited to one application. This allows different applications to use the same credential store without conflict with each other's user name or role. Asp. NET provides support for credential stores such as SQL Server, Windows, and active directories (see Figure 1). In order to install the SQL Server voucher database, you can run the Aspnet_regsql.exe program at the following location:
<WINDOWS> \microsoft.net\framework\ <version>
This installer creates a new database called ASPNETDB-it contains tables, users, roles for a set of applications, and stored procedures to access those tables. This SQL Server database is carefully designed using the latest security technologies. In addition, ASP.net 2.0 provides a set of classes corresponding to the provider (Figure 1).
Information about which provider is used is saved in the application's configuration file (app.config or web.config). You hardly need to interact directly with a particular provider; instead, there are two static helper classes: Membership and roles-They are responsible for reading from the configuration file which provider to use. The default provider (that is, when no provider is specified) is SQL Server. The Membership Class (Listing 1) allows you to create and delete users, retrieve information about users, and view password policies.
List 1:membership Assistant class
[Serializable]
public class membershipuser{
Public virtual bool ChangePassword (string oldpassword,string newpassword);
Public virtual string GetPassword (string passwordanswer);
Public virtual string ResetPassword (string passwordanswer);
Public virtual bool Unlockuser ();
Other Members
}
public static Class membership{
public static string Applicationname{get;set;}
public static MembershipUser CreateUser (string Username, string password);
public static MembershipUser CreateUser (string username,
string password, string email, string passwordquestion,
String passwordanswer, bool isapproved, out membershipcreatestatus status);
public static bool DeleteUser (string Username,bool deleteallrelateddata);
public static MembershipUser GetUser (string username);
public static void UpdateUser (MembershipUser user);
public static bool ValidateUser (string username,string password);
public static bool Enablepasswordreset{get;}
public static bool Enablepasswordretrieval{get;}
Other Members
}
For example, to create a new user in a "MyApp" application, you only need to encode the following:
Membership.applicationname = "MYAPP";
Membership.CreateUser ("MyUser", "MyPassword",...);
The roles class allows you to create and delete user roles, add or remove users from roles, retrieve user role membership information, and validate role members. The following is the definition of the class:
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);
Other Members
}
For example, to add the role "Manager" to the Application "MyApp", you can encode the following:
Roles.applicationname = "MYAPP";
Roles.createrole ("Manager");
second, management voucher storage
If you choose to use Windows or active directories to store the users and roles of your application, you need to use the tools appropriate to these storage, such as the Computer Control Panel applet or the Active Directory tool. In fact, the real problem is how to manage the credentials stored in SQL Server. To do this, you can use Visual Studio 2005 and a Web browser without even having to install IIS. In a asp.net Web project, select ASP from the "Website" menu. NET Configuration ". This will allow Visual Studio to host a Web server, open an available port and navigate to a set of administration pages (see Figure 2). These administration pages modify the Web application configuration file and can also manage the voucher store (when Windows authentication is not selected). When using Visual Studio 2005, you first need to select the authentication type. You can choose Windows or form authentication (Internet access). If you select Form authentication, you can also do the following:
• Enable or remove role-based security
• Create and delete roles
• Create and delete users
• Retrieves the details of a user
• Set the status of a user
• Assigning a role to the user
• Remove users from the role
Figure 2. asp.net Web Application Management page
Now that SQL Server is the only enterprise-class custom credential store provided by ASP.net 2.0, you can use the Visual Studio 2005-driven management page alone to manage the ASPNETDB database without any other storage.
third, the lack of built-in functions
There are some important drawbacks to the Visual Studio 2005-driven Management page: First, you need Visual Studio 2005. The application or system Superuser may not have visual Studio 2005, let alone how to use it. By default, the Administration page uses a slash (/) to manage application naming and does not provide any modification methods. Second, remote access cannot exist-applications and Visual Studio 2005 must coexist so that Visual Studio 2005 can access the application's configuration file. Third, the browser-based user interface is not very friendly-you need to keep clicking on the Back button, and the user interface is pretty dull. In addition, many of the features that a superuser might want to use cannot be implemented through page management, which is divorced from the fact that the underlying provider class supports features. The areas that are not yet achievable are:
• Update most user account details
• Retrieve, change, and reset a user's password
• Retrieve the current number of users online
• Ability to remove all users from one role in one operation
• Retrieve information about password management policies (such as length, reset policy, password type, and so on)
• Test user credentials
• Verifying User Role identity
And there are other features that super users might want that are not supported. These features include the ability to retrieve all of the database application lists, to remove all users from an application, to remove all roles from an application, to remove an application (and all of its associated users and roles), and to remove all applications. In summary, although ASP.net 2.0 provides a first-class comprehensive credential management, it provides only a few of the original management options that the average actual superuser will not use.
Figure 3. A snapshot of the voucher manager application
All this prompted me to develop a custom client Credential Manager application to compensate for these deficiencies. Figure 3 shows a snapshot of the program. The following section describes how I designed and built the voucher manager.
