The AspNetLoginControl

Example B-3 shows the definition of AspNetLoginControl.

Example B-3. The AspNetLoginControl class

 public partial class AspNetLoginControl : LoginControl {    protected override IUserManager GetUserManager(  )    {       return new AspNetUserManager(  );    } }

AspNetLoginControl derives from LoginControl, and in its overriding of GetUserManager( ) it returns the AspNetUserManager implementation of IUserManager, which uses the ASP.NET providers directly (see Figure B-4).

AspNetUserManager is capable of using any valid ASP.NET 2.0 provider (hence its name). To use AspNetLoginControl, you will need to add to the application's configuration file the same values you would have placed in a web application configuration file, indicating which provider to choose as well as any provider-specific values and settings.

For example, to use the SQL Server provider (which is the default provider), add the settings shown in Example B-4 to the application configuration file. The connection string value shown in Figure B-4 is used to connect to the aspnetdb database on the local machine after default installation. Note the use of the enabled attribute of the roleManager tag to enable authorization.

Figure B-4. The AspNetLoginControl control

Example B-4. Settings for AspNetLoginControl

 <?xml version="1.0"?> <configuration>    <system.web>       <roleManager enabled="true"/>    </system.web>    <connectionStrings>       <remove name="LocalSqlServer"/>       <add name="LocalSqlServer" connectionString="          data source=(local);Integrated Security=SSPI;          Initial Catalog=aspnetdb"/>    </connectionStrings> </configuration>

Implementing IUserManager

AspNetUserManager contains as member variables instances of the ASP.NET membership and role providers. All the functionality of IUserManager is accomplished by delegating to the ASP.NET providers (see Example B-5).

Example B-5. The AspNetUserManager class

 class AspNetUserManager : IUserManager {    public bool Authenticate(string applicationName,string userName,string password)    {       Membership.ApplicationName = applicationName;       return Membership.ValidateUser(userName,password);    }    public bool IsInRole(string applicationName,string userName,string role)    {       Roles.ApplicationName = applicationName;       return Roles.IsUserInRole(userName,role);    }    public string[] GetRoles(string applicationName,string userName)    {       Roles.ApplicationName = applicationName;       return Roles.GetRolesForUser(userName);    } }

To implement Authenticate, AspNetUserManager calls the ValidateUser( ) method of Membership. To implement IsInRole and Getroles, AspNetUserManager calls the IsUserInRole( ) and GetrolesForUser( ) methods of Roles.

By default, NTFS security enforces access permission security to the application configuration file, so that only application administrators can modify the provider's settings.

AspNetLoginControl and Code Access Security

AspNetLoginControl works well, and you can certainly use it. However, it does have one important shortcoming you should be aware of. The ASP.NET providers were designed to be used on the server, and they require a few nontrivial permissions: unmanaged code access permission, unrestricted SQL Client access permission, and minimal ASP.NET Hosting permission. Typically, server-side applications run in an elevated trust environment (see Chapter 12 for a recommended server-side policy), potentially even full-trust, and will have no problem obtaining those permissions and executing properly.

AspNetLoginControl, on the other hand, is going to be used by Windows Forms applications. It is quite likely that such applications will be executing in a partial-trust environment, perhaps as ClickOnce applications. The client environment may very well not grant the applications using AspNetLoginControl the permissions they require to operate.

Table B-1 lists the permissions required for AspNetLoginControl and who demands them. These permissions are the product of both the control itself and the components it uses: CustomPrincipal and AspNetUserManager.

Table B-1. Security permissions required by AspNetLoginControl

Permission type	Specific permission value	Demanded by
Security	Execution	Any managed application, in order to run
Security	Unmanaged code access	The ASP.NET providers
ASP.NET Hosting	Minimal	The ASP.NET providers
SQL Client	Unrestricted	The ASP.NET providers, for accessing the database
Reflection	Unrestricted	EventsHelper, when using dynamic invocation of the login event
User Interface	Safe sub-windows	LoginControl, in order to display itself
Security	Control principal	CustomPrincipal, in order to set the principal policy and attach itself

You have a number of options in choosing how to deal with these permission demands. You can grant full trust to the WinFormsEx.dll assembly and all its clients, but that is unadvised, as discussed in Chapter 12.

Alternately, using the .NET Configuration tool, you can grant most of these permissions both to the WinFormsEx.dll assembly and to every client application that wants to use it. You can also list these permissions in the ClickOnce application manifest. To ease the task of granting the permissions, the source files accompanying this book contain the WinFormsEx.xml fileit's a custom permission set file that you can add to the .NET Configuration tool to grant the necessary permissions.

However, the best solution is to avoid the permissions demanded by the ASP.NET providers altogether and use a different implementation of IUserManagerone that does not demand server-side permissions in a client environment. This option is presented next.