Disabling Authentication

The Access Control tab in the properties of your application allows you to manage authentication. By default, LightSwitch disables authentication in all new projects that you create. (See Figure 16-1.)

You would leave authentication disabled if you have no need to know who your users are. This choice is suitable if you want to give users open access to your application and have no need to control access to specific parts of your application.

Enabling Windows Authentication

To enable Windows authentication, select the Use Windows Authentication radio button. (See Figure 16-2.) This enables an additional set of radio buttons that allows you to choose who can run your application.

The first option requires you to enter each Windows user who wants to access your application. You would do this at runtime by using the Users screen. (See Figure 16-3.)

The second option (Allow Any Authenticated Windows User) allows all users who have been authenticated by Windows to run your application. This option is ideal if you want to identify your users without going through the time-consuming process of adding each user to your application. If you enable this option, you can still restrict the tasks that individual users can carry out in your application by specifying their login names in the Users screen. Chapter 17 covers this in greater depth.

When you deploy your application, you’ll need to designate an application administrator by using the publish wizard. Chapter 18 shows you the specific steps that you would follow to set up an application administrator.

Enabling Forms Authentication

When you choose Use Forms Authentication (shown in Figure 16-4), your application prompts the user for a user name and password at startup. Forms authentication uses a set of application-defined identities that are created by your application administrator.

There are a couple of security considerations that you should to be aware of. Forms authentication can be regarded as a less secure option, because your users’ user names and passwords are stored in a database table rather than being securely maintained by Windows. Although LightSwitch stores the cryptographic hash of the passwords rather than the clear-text values, this might still be considered a security risk.

Second, the user name and password details that a user enters at logon are transmitted in clear text across the network. An attacker who snoops the network might discover the user names and passwords that are being used. Enabling HTTPS on your server helps to mitigate this risk.

The application administrator creates the user names and passwords at runtime by using the Users screen, which was shown in Figure 16-3. The administrator can also use this screen to delete users or reset passwords.

If users want to change their password, they can do so by using an option that’s shown by LightSwitch. (See Figure 16-5.) The location of the control that opens the Change Password dialog depends on the shell that you’ve chosen. In the Standard shell, the control appears in the bottom right part of the application.

Changing the Password Complexity Rules

When you enable Forms authentication, the membership provider enforces a password-complexity rule that helps to keep your application secure. By default, passwords must be eight characters in length and contain a non-alphanumeric character. An example of a valid (but absurdly weak) password is pass@word1.

The default rule provides a good level of security, but some users might find it too restrictive and you might prefer to weaken the rule. Alternatively, you might even want to strengthen the password-complexity rule to force users to use passwords that are even more complex.

After you deploy your application, you can change the password-complexity rule by modifying a setting in your web.config file. When you deploy your application in Internet Information Services (IIS), you’ll find the web.config file in the root folder of your LightSwitch application. As mentioned earlier, Forms authentication isn’t recommended for two-tier applications; therefore, this section applies only to three-tier IIS deployments.

Once you find your web.config file, open it in a text editor and search for the ASPNetSQLMembershipProvider element. The membership provider controls the password complexity through the minRequiredPasswordLength and minRequiredNonalphanumericCharacters attributes (shown in Figure 16-9). If these two attributes don’t exist, you can simply add them in.

Changing Password-Encryption Settings

By default, LightSwitch saves the hashes of the user passwords rather than the clear-text password. This is controlled by the passwordFormat attribute in the AspNetSqlMembershipProvider element of your web.config file (which you also can see in Figure 16-9). There are three choices that you can enter here:

• Hashed
• Encrypted
• Clear

Hashed is the default value and the most secure. When you choose this option, LightSwitch uses a one-way hash algorithm and a randomly generated salt value to encrypt the passwords that it stores in the database. When a user enters a user name and password at logon, LightSwitch hashes the password that is entered and compares it to the value that’s stored in the database.

It’s impossible for you to retrieve the plain-text password values when passwordFormat is set to Hashed. If you want your user passwords to be stored in plain text inside your aspnet_users table, change the passwordFormat setting to Clear. This is obviously less secure because anyone who can access the aspnet_users table can see all your passwords.

Although this is less secure, there are a couple of reasons why you might choose this option:

• You might want to build some mechanism outside of LightSwitch to remind users of their actual password.
• During the initial setup of your application, you might want to pre-load users and known passwords by manually populating the aspnet_users table. Maintaining clear-text passwords simplifies this process and saves you from having to create some additional process to work out the hash or encrypted value.

Sharing Forms Authentication Data with ASP.NET

Let’s imagine that you have an existing ASP.NET web site that uses Forms authentication. Because your web site already contains a set of users, you might want to share these existing credentials with your LightSwitch application. You can set up your LightSwitch application to share Forms authentication details with existing ASP.NET web sites by modifying your web.config file.

To do this, deploy your LightSwitch application to IIS and open the web.config file in a text editor. (See Chapter 18 for more help on deployment.) You’ll need to make the following changes to this file:

• Create a new connection string that points to the authentication database that your existing ASP.NET application uses.
• Update the membership, role, and profile provider strings to reference the connection string that you’ve created.
• Ensure that the same ApplicationName is specified in the provider strings in both your LightSwitch and ASP.NET applications.
• Specify the same machine key setting for both of your applications.

To create a new connection string that references the authentication database that your existing ASP.NET application uses, search for the connectionStrings element. Beneath the _IntrinsicData connection string that’s created by LightSwitch, create a new connection string that points to your existing authentication database (highlighted in Figure 16-10). The new connection string in this example is called _AuthData.

Now search for the AspNetMembershipProvider, AspNetRoleProvider, and AspNetProfileProvider entries in the web.config file of your LightSwitch application. By default, the connectionStringName setting for each entry is set to _IntrinsicData by default. Change this to _AuthData (as shown in Figure 16-11).

Open the web.config file for your existing ASP.NET application, and search for the AspNetMembershipProvider entry. Find the applicationName that this uses. In this example, let’s assume that the applicationName value is set to ExistingASPApp.

Make sure that the three provider strings in the web.config file for your LightSwitch application specify the applicationName of ExistingASPApp.

You need to have the same machine key defined in both of your applications. Because passwords are hashed (or encrypted), identical machine keys allow both applications to encrypt and decrypt passwords in the same exact way.

If a machine key isn’t specified in the web.config file of your existing application, you’ll need to generate a new key. IIS Manager includes a feature that generates machine keys for you. (See Figure 16-12.) Alternatively, you can search the Web to find online web sites that can generate keys for you. Once you’ve decided on a key, add the machine key entry to the <system.web> section in both of your web.config files. Figure 16-13 shows how this looks.

Allowing Users to Log Out of Web Applications

Silverlight LightSwitch browser applications don’t include a Logout button, so the only way for a user to log out of a Forms authenticated application is to close their browser.

This behavior isn’t convenient for someone who wants to quit their session and log in as a different user. This example shows you how to add a Logout button to save your users the trouble of closing and reopening their browser.

This technique uses an ASP.NET page to kill the current session, and reloads the web page that hosts your LightSwitch application.

First of all, you’ll need to deploy your application into IIS. (Refer to Chapter 18 for details.) Create a new text file in the web-site folder that contains your LightSwitch application. Now add the content that’s shown in Listing 16-1, and rename your file to LogOff.aspx.

Listing 16-1.  Logoff.aspx Code-Behind

VB:
File:HelpDeskVBServerLogoff.aspx
<%@ Page Language="vb" %>
<%
System.Web.Security.FormsAuthentication.SignOut()
Response.Redirect("default.htm")
%>
  
C#:
File:HelpDeskCSServerLogoff.aspx
<%@ Page Language="C#" %>
<%
System.Web.Security.FormsAuthentication.SignOut();
Response.Redirect("default.htm");
%>

To call this web page, create a button called Logout on your Engineer Dashboard screen and add the code shown in Listing 16-2. You can use the Properties sheet to set an icon for your button. For the code to work, you’ll need to switch to File view and add a reference to the System.Windows.Browser assembly in your Client project. You’ll also need to include the imports or using statements shown in the listing.

Listing 16-2.  Execution Code for the Logout Button

VB:
File: HelpDeskVBClientUserCodeEngineerDashboard.vb
  
Imports Microsoft.LightSwitch.Threading
Imports System.Windows.Browser
Imports Microsoft.LightSwitch.Security
  
Private Sub Logout_Execute()
   Dispatchers.Main.Invoke(
      Sub()
         HtmlPage.Window.Navigate(
            New Uri("LogOff.aspx", UriKind.Relative))                        
      End Sub)
End Sub
  
Private Sub Logout_CanExecute(ByRef result As Boolean)
  
   Dim logoutCanExecute As Boolean
   Dispatchers.Main.Invoke(
      Sub()
         logoutCanExecute =
            (System.Windows.Application.Current.IsRunningOutOfBrowser =
                 False) AndAlso
             (Application.Current.User.AuthenticationType =
                 AuthenticationType.Forms)
       End Sub)
  
    result = logoutCanExecute                                                

End Sub
  
C#:
File: HelpDeskCSClientUserCodeEngineerDashboard.cs
using Microsoft.LightSwitch.Threading;
using System.Windows.Browser;
using Microsoft.LightSwitch.Security;
  
partial void Logout_Execute()
{
    Dispatchers.Main.Invoke(() =>
    {
        HtmlPage.Window.Navigate(
            new Uri("LogOff.aspx", UriKind.Relative));                       
    });
}
  
partial void Logout_CanExecute(ref bool result)
{
   bool logoutCanExecute = false;
   Dispatchers.Main.Invoke(() =>
   {
      logoutCanExecute =
         (System.Windows.Application.Current.IsRunningOutOfBrowser == false)
            && (Application.Current.User.AuthenticationType ==
                AuthenticationType.Forms);
    });
  
    result = logoutCanExecute;                                                
}

The code in the Logout_Execute method navigates the user to the LogOff.aspx page . This page contains the logic that signs out the user. The code in the Logout_CanExecute method hides the Logout button if you haven’t enabled Forms authentication or if your application isn’t running in a browser.

When the user now runs your application, they’ll be able to log out of your application by clicking on the Logout button. (See Figure 16-14.)

If you want to show a logout command that appears throughout your application, you can attach the logout code to a navigation menu rather than to a button. To do this, you would create a dummy screen and add code to its _CanRun method. The “Opening Screens Conditionally at Login” section in Chapter 17 demonstrates this technique.