The WSLoginControl

WinFormsEx.dll contains the definition of WSLoginControl, shown in Example B-7.

Example B-7. The WSLoginControl class

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

WSLoginControl derives from LoginControl, and in its overriding of GetUserManager( ) it returns UserManager, a client-side web service proxy class used to invoke the UserManager web service. WSLoginControl can use any web service that manages user credentials, as long as it supports the IUserManager interface (hence its name). To generate the proxy class, add a web reference to the UserManager web service. Add to the machine-generated UserManager web service proxy class derivation from IUserManager. Since the proxy class is a partial class and is machine-generated, add that code, preferably in a separate file:

     partial class UserManager : IUserManager     {}

WinFormsEx.dll already contains the definition of the UserManager web service proxy class. The code in the proxy class looks up the web service address from the application configuration file. Under the appSettings section, add to the application configuration file a key called UserManager, whose value is the web service address:

     <?xml version="1.0"?>     <configuration>        <appSettings>           <add key="UserManager"                value="http://localhost/SecurityServices/UserManager.asmx"/>        </appSettings>     </configuration>

Figure B-5 shows WSLoginControl and CustomPrincipal, and their interaction with the UserManager web service.

Figure B-5. WSLoginControl and its supporting classes

WSLoginControl and Code Access Security

Using a web service keeps the ASP.NET providers' permission demands on the server. The trade-off is that you will need instead to grant the clients web access permission to connect to the UserManager web service. You will also need to grant the rest of the permissions required by LoginControl and CustomPrincipal. Table B-2 lists the reduced permissions required when using a credential-management web service.

Table B-2. Security permissions required by WSLoginControl

Permission type	Specific permission value	Demanded by
Security	Execution	Any managed application, in order to run
Web Access	Connect to the UserManager web service	The UserManager proxy class, to be able to use the web service
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

Using the .NET Configuration tool, you can grant the permissions from Table B-2 both to the WinFormsEx.dll assembly and to every client application that wants to use it. You can also use Visual Studio 2005 to list these permissions in the ClickOnce application manifest. In Visual Studio 2005, go to the Security tab in the project settings of a ClickOnce application that uses WSLoginControl. Check the "Enable ClickOnce Security Settings" checkbox and select the "This is a partial trust application" radio box. Under "Zone your application will be installed from", select (Custom). This will remove all permissions except execution permission. Next, select SecurityPermission, and under Settings select Include.

Click Properties... to bring up the Permission Settings dialog shown in Figure B-6.

Figure B-6. Granting execution and principal control permissions

Select the assembly execution and principal control permissions, and click OK. To grant permission to call the web service, include the Web Access permission; in its properties, specify the UserManager's URL and allow the application to connect to it (see Figure B-7).

Figure B-7. Granting web service invocation permission

In a similar manner, grant the rest of the permissions from Table B-2 (User Interface and Reflection). When you publish your ClickOnce application, its application manifest will include these permissions. You can even use Visual Studio 2005 to debug the application under these partial-trust settings.