In the next two chapters, I’ll show you how to secure your LightSwitch application. This chapter covers authentication—the process that determines the identity of your user. Once you identify your user, you can control the screens that they can see and functions that they can perform in your application. I’ll cover this process in the next chapter (Chapter 22), which is on authorization. In this chapter, you’ll learn how to do the following:

• choose an authentication method that suits your application type
• apply Windows or Forms authentication in your LightSwitch application
• share authentication credentials with other applications

By the end of this chapter, you’ll understand how to enable authentication in your applications. You’ll also have discovered how to force users to enter a username and password at login by enabling Forms authentication.

Choosing an Authentication Method

LightSwitch supports two authentication methods: Windows and Forms. When you enable Windows authentication, LightSwitch identifies the logged-in user by using the credentials that they use to log in to their Windows computer.

Forms authentication identifies a user by forcing them to enter a username and password when the application starts. Your application type determines the most appropriate type of authentication. Table 21-1 summarizes the options that work best, based on application type.

The most secure choice for a two-tier desktop application is Windows authentication. In a two-tier application, LightSwitch stores the connection string to your membership database in clear text inside your application’s web.config file, which it stores on the client’s machine. If a malicious user discovers this connection string, they could tamper with your membership data outside of LightSwitch.

If you want to make your application available via the Internet (or to deploy to Azure), Windows authentication isn’t really a viable choice. Forms authentication is the best choice in this scenario.

In a three-tier local network deployment (with the LightSwitch server components hosted in IIS), you have a choice of either Windows or Forms authentication. Table 21-2 summarizes the features of these two authentication types and explains when to use each type.

No Authentication

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

You would leave authentication disabled if you have no need to know who your users are. This choice is appropriate if you want to provide open access to your application, with no need to control access to certain parts of your application.

Enabling Windows Authentication

To enable Windows authentication, select the “Use Windows authentication” radio button (Figure 21-2). This enables an additional set of radio buttons you can use to choose who can run your application.

The first option requires you to enter each Windows user who can access to your application. You would do this at runtime via the users screen.

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, but don’t want to go 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 user screen. Chapter 22 will cover this in greater depth.

When you deploy your application, you need to designate an application administrator during the publish process. Chapter 23 will describe the publishing process and show you the specific steps that you need to follow.

Forms Authentication

When you choose Forms authentication (Figure 21-4), your application will prompt the user for a username and password at start-up. Forms authentication is based on username and password combinations that the application administrator defines.

There are a couple of security considerations you should to be aware of. First, some IT professionals regard Forms authentication as a less secure option because it stores the usernames and passwords in a database table. For additional security, LightSwitch stores the cryptographic hash of the passwords rather than the clear-text values. Despite this, some administrators may consider this a security risk in environments that need to be very secure.

Second, LightSwitch transmits the username and password combination that the user enters at login in clear text across the network. An attacker who snoops the network can discover the usernames and passwords being used. You can help mitigate this risk by enabling HTTPS on your server.

The application administrator creates the usernames and passwords at runtime through the users screen, shown in Figure 21-3. The administrator can also use this screen to delete users and to reset passwords.

If users want to change their password, they can do so by using an option that LightSwitch provides (Figure 21-5). The location of the control that opens the Change Password dialog depends on the shell that you choose.

Understanding Where User Details Are Stored

When you enable authentication, LightSwitch manages your users with the ASP.NET membership provider, which stores your users in a table called aspnet_Users in the Intrinsic database. Figure 21-6 shows a screenshot of this table. The primary-key field is called UserId and is of data type GUID. The provider stores the usernames in a field called UserName.

LightSwitch stores the roles you define in a table called aspnet_Roles. This is shown in Figure 21-7.

The user-to-role settings are stored in a table called aspnet_UsersInRoles. The set of tables that the membership provider uses and the relationships between them are shown in Figure 21-8.

It’s useful to understand the tables that the membership provider uses, because it enables you to create and retrieve user accounts outside of LightSwitch. If you’re familiar with SQL Server, you know you can create users by calling the aspnet_Membership_CreateUser and aspnet_Profile_SetProperties stored procedures.

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 not very strong) 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 this rule. Alternatively, you might even want to strengthen the password complexity rule to insist that users create more-complex passwords.

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 IIS, you’ll find web.config in the root folder of your LightSwitch application. As I mentioned earlier, Forms authentication doesn’t provide sufficient security for two-tier applications—this section therefore focuses on the three-tier IIS setup.

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 21-9). If these two attributes don’t exist, you can simply add them to your file.

Changing Password Encryption Settings

By default, LightSwitch saves the hashes of the user passwords rather than the clear-text password. The passwordFormat attribute in the AspNetSqlMembershipProvider element of your web.config file controls this behavior (which you can also see in Listing 21-1). There are three choices that you can enter here:

• Hashed
• Encrypted
• Clear

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

It’s impossible for you to retrieve the plain-text password values when you set the passwordFormat to Hashed. If you want to store your user passwords 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 of your passwords.

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

• You might want to build some mechanism outside of LightSwitch to remind users of their actual password.
• During the initial set up 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 means that you don’t need to create an 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 website that uses Forms authentication. Because your website 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 websites 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 23 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 just created.
• Ensure that you specify 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 used by your existing ASP.NET application, search for the connectionStrings element. Beneath the _InstrinsicData connection string that LightSwitch creates, add a new connection string that points to your existing authentication database (as highlighted in Figure 21-10). In this example, I’ve named this new connection string _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 21-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.

Return to the web.config file for your LightSwitch application and set the applicationName of the three provider strings to ExistingASPApp.

You need to define the same machine key in both of your applications. Because LightSwitch hashes (or encrypts) passwords, identical machine keys allow both applications to encrypt and decrypt passwords in the same exact way.

If a machine key doesn’t exist 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 (Figure 21-12). Alternatively, you can search the web to find online websites that can generate keys for you. Once you create a new key, add the machine-key entry to the <system.web> section in both of your web.config files. Figure 21-13 shows how this looks.

Allowing Users to Log Out of Desktop Web Applications

LightSwitch desktop browser applications don’t include a Log Out button, and 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 users who want to quit their session and to log in as a different user. In this section, I’ll show you how to add a Log Out button to make it easier for users to login with a different set of credentials.

When you create an application, LightSwitch creates a web page called LogOut.aspx in your server project. This web page provides the mechanism that allows HTML client users to log out of their sessions. To implement the same functionality in desktop browser applications, the technique that I’ll describe will call this page from a screen button.

The first step is to add a reference to the System.Windows.Browser assembly in your desktop client project. Next, create a button on your screen called Logout and add the code shown in Listing 21-1. Make sure to include the imports or using statements that are shown in this listing.

To test this code, you need to first deploy your application onto an IIS server. Once you deploy your application, copy the LogOff.aspx file from the root of your website into the DesktopClient subfolder.

The code in this listing navigates the user to the LogOff.aspx page . This page terminates the user session and reloads your application. As a matter of good practice, the code in the CanExecute method hides the Logout button if Forms authentication is not enabled, or if your application is not configured as a browser application. Figure 21-14 shows the appearance of the Logout button at runtime.

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 22 demonstrates this technique.

Summary

Authentication enables you to determine the identity of your user, which in turn allows you to control what the user can do in your application.

There are two types of authentication that you can use: Forms authentication and Windows authentication. Windows authentication is the most secure method for a two-tier desktop application.

Windows authentication utilizes the credentials that your user inputs to log in to their Windows computer. The benefit of this method is that users don’t need to supply additional credentials when they start your application.

Forms authentication is perfect for Internet applications, or for environments that don’t have a Windows domain. If you enable Forms authentication, LightSwitch prompts the user to enter a username and password at login.

For both types of authentication, the administrator enters the user data through a screen that LightSwitch provides at runtime.

LightSwitch uses the ASP.NET membership provider to manage your users. This provider stores your user data in tables inside your Intrinsic database.

If you choose Forms authentication, your passwords must be eight characters in length and contain a non-alphanumeric character. You can change this rule by amending your web.config file. This file also allows you to configure how the provider encrypts the passwords in your database.

You can share your Forms authentication credentials with other LightSwitch or ASP.NET applications by modifying your web.config file. This change will allow users to log in to different applications using the same username and password. To set this up, you need to amend the user, role, and profile providers in all systems so that they use the same authentication database and machine key.

LightSwitch desktop browser applications don’t include a Logout button. So, if you want to add this ability, you can add a button to your screen to call a web page that logs off your user.