October 2011

Volume 26 Number 10

LightSwitch Security - Securing Access to LightSwitch Applications

By Valerie Andersen | October 2011

Let’s face it: Implementing application security can be daunting. Luckily, Visual Studio LightSwitch makes it easy to manage permissions-based access control in line-of-business (LOB) applications, allowing you to build applications with access-control logic to meet the specific needs of your business.

A LightSwitch application logically consists of three tiers: presentation, logic and data storage, and you’ll need to consider access to assets at each tier in order to ensure the right level of access is achieved. With LightSwitch, you can build access-control logic into applications at the right level. Moreover, you’ll find that LightSwitch leverages the access-control fundamentals in the underlying technologies and allows for common access-control configuration through IIS and ASP.NET.

This article examines how access control works in LightSwitch applications. First, we’ll describe the features LightSwitch provides for access control in a three-tier architecture. Next, we’ll briefly review deployment as it pertains to access control and show some ways to further control access using the technologies that support LightSwitch. Finally, we’ll discuss access control when deploying to an Azure environment.

Access Control Basics

There are two aspects to access control in LightSwitch applications. The first is authentication, or how an application verifies a user is who he says he is. The second is authorization, which defines what the user is allowed to do or see in the application.

Authentication

The authentication process determines if a user is who he claims to be. The first layer of access control in LightSwitch requires users to identify themselves to the application. The supported authentication modes are Windows authentication and Forms authentication. These options can be configured in the application properties Access Control tab of your application, as seen in Figure 1.

Figure 1 Defining Permissions in the Application Designer

Windows authentication is recommended when all users are on a Windows domain and you trust that the person logged into a computer is the same user who’s using the application. Windows authentication doesn’t require an additional login prompt and the application doesn’t have to store or manage passwords outside of Windows. Windows authentication is the more secure option, but it’s usually only practical if the application is running in a corporate intranet environment with a domain.

With the second option, Forms authentication, the user is prompted for a username and password when the application opens. In LightSwitch, these values are checked against a database by default. Forms authentication works nicely for clients running across the Internet or for those not on a Windows domain.

Forms authentication requires that any users needing access to the application first be added to the system. Windows authentication can work this way as well, but there’s an option that can be set at design time to allow all Windows users who can log in to the domain to have access to the application by default. Any parts of the application requiring specific permissions would not be accessible to a Windows user who hasn’t been explicitly added.

Authentication lets you identify who can or can’t use the application, and it may be all that’s required to meet the access-control needs for some kinds of applications. Once users are authenticated, you may choose to fully trust them with access to the data. In that case, your access-control implementation is complete and no additional permissions or code are required. You need only consider the IIS options discussed in the Deployment Considerations for Access Control section for securing your application on the hosting server.

However, many applications require more granular control of users’ behavior after they’ve been authenticated. For these scenarios, you’ll need authorization.

Authorization

LightSwitch provides a permissions-based authorization system for developing business rules, as shown in Figure 2.  

Figure 2 Implementing Authorization in LightSwitch

You define permissions in the application designer (see Figure 1). You can then write code to check if the current user has the required permissions. Access-control methods can be implemented on entities, queries and screens, so you can easily write logic to determine if the current user can view or manipulate specific data or open a particular screen.

LightSwitch has a built-in permission called Security Administration, and any user who receives this permission becomes a security administrator. The Security Administration permission allows the logged-on user to access the Security Administration screens in the running LightSwitch client application, which will show automatically for users who have been granted this privilege. The security administrator creates the roles needed for the application and assigns the desired permissions to each role, as shown in Figure 3. Then, users are created and assigned to the appropriate role, as shown in Figure 4.

Figure 3 Creating Roles at Run Time

Figure 4 Assigning Users to Roles at Run Time

When an application is first deployed, a security administrator must be added to the Security Administration role to enable initial access to the application. The deployment process assists in configuring this default user appropriately. When a deployed application is running, the system will not allow the removal of the last user having the security administrator permission to ensure that a security administrator exists at all times.

However, you won’t have to deploy your application to verify the appropriate permission behavior. When you run a LightSwitch application in debug mode, the authentication and role system run in a special mode in which the development environment automatically tries to authenticate a special test user. You can grant or deny the permissions the test user has from the LightSwitch designer using the “Granted for debug” column. Then the application will run in debug mode with the permissions selected so you can test the written permission logic. This means you can quickly validate that the permission checks are accurate without having to configure multiple test users and roles.

Where You Control Access to Application Assets Matters

Now let’s consider what to secure and where to secure it. Many applications have some sensitive data that needs to be protected from view, other data that only needs to be guarded against manipulation, and possibly some data that doesn’t need protected access at all. The first place to think about securing data should be the logic tier. When developers control data appropriately at the logic tier, the presentation tier will often react correctly and automatically. For example, if a user doesn’t have the delete permission granted for Employee data, a grid showing Employee data will have the delete button disabled. That’s the power and ease of building applications with LightSwitch.

Implementing access control at the data level makes the application more secure and lets developers take advantage of built-in intelligence. Securing data only at the presentation tier leaves your data exposed at the logic tier. A malicious, authenticated user could bypass the presentation tier and access the service directly to read or manipulate data. This relates to the three-tier architecture of LightSwitch applications and, in fact, is common among three-tier applications. The presentation tier is responsible for displaying the data appropriately; however, it’s not the only way for an authenticated user to access the data if the proper access controls aren’t implemented on the logic tier.

Securing Data on the Logic Tier

The logic tier includes two major groups of components where you apply permissions checking: entities and queries.

Entities Entities are the general mechanism for accessing and working with application data. There are four main actions you can carry out with entities: read, insert, update and delete. LightSwitch gives developers a hook-point to verify a user’s permissions as each action is carried out, and it also provides a simple API for checking if the current user has a specific permission defined in the application. The following code shows an example of the permissions check and the various gate methods the API provides to allow a developer to check permissions:

partial void Employee_CanUpdate(ref bool result)
{
  result = Application.Current.User.HasPermission(Permissions.EmployeeUpdate);
}
partial void Employee_CanInsert... 
partial void Employee_CanRead... 
partial void Employee_CanDelete... 
partial void SaveChanges_CanExecute...

A couple of things should be noted. First, these methods, with the exception of SaveChanges_CanExecute, are implemented on the entity set as a whole and not on the specific entity instances. Therefore, any checks performed can’t be related to data values on a specific entity instance. The SaveChanges_CanExecute method controls access to changes in the entire data source and therefore can’t contain entity- or entity-set-specific logic. Second, if the Employee_CanRead method returns false, the Employee_CanUpdate and Employee_CanDelete methods will not be called, as they would be implicitly false as well. A user is not allowed to update or delete an entity if she isn’t allowed to read it.

The “Can” methods are the basic way to do coarse-grained security. They support basic data access-control policies. However, they have some limitations. When more fine-grained control for reading data is needed, you can implement access-control logic on queries. To control the writing of data at a more granular level, you must do so in the Save Pipeline.

Queries Queries are also secured on the logic tier. Each query has a method that allows you to control access. LightSwitch automatically generates three queries for each entity that exists: an All query to return all of the entity instances, and Single and SingleOrDefault queries to return one entity instance by key. Each of these built-in queries has a CanExecute method that can be used to implement access control:

partial void Employees_All_CanExecute(ref bool result)
{
  result = Application.Current.User.HasPermission(Permissions.QueryEmployees);
}
 
partial void Employees_Single_CanExecute...
partial void Employees_SingleOrDefault_CanExecute...

It’s important to note that LightSwitch queries are composable, meaning new queries can be based on an existing query. When applying access-control logic to queries, the permission requirements on the initial query serve as input to queries composed on that query. The Single and the SingleOrDefault queries are composed on the All query, so securing the All query also secures these queries if no specific permissions are specified for the derived query. However, if you like, you can specify permissions on the derived query that are less restrictive than those on the composing query. Also, the CanRead method on the entity set will be applied before CanExecute for any queries of that type.

Figure 5 shows an example of query composition—if the NorthAmericaEmployees query is created on the Employee entity, this query is composed on the built-in Employee_All query. Therefore, any access-control logic applied via Employee_All_CanExecute will also apply to 
the NorthAmericaEmployees query because the NorthAmericaEmployees query is based on the Employee_All query, assuming no specific code is written for the derived query. If you wanted to allow only certain users to access the data in the NorthAmericanEmployees entity, you could specifically restrict or open up the permissions for that query via the NorthAmericaEmployees_CanExecute method.

Figure 5 Query Composition on the Employee Entity

Controlling Access Across Relationships

When working with queries across relationships, it’s important to understand that permissions are checked on the entities as relationships, which are traversed across related entities. This is another reason why it’s important to have permissions properly defined on the entities. If you need to protect data from read access through relationships, the CanRead method on the entity needs to require the correct level of permission. As an example, let’s consider our Employee table again and the related compensation data, as shown in the model in Figure 6.

Figure 6 HR Application Model

When traversing the relationship between Employee and Compensation via a query, the permissions on the entity read actions are evaluated as the relationship is traversed rather than the permissions on the Compensation_All_CanExecute. The permissions must be correctly set on the Compensation entity’s CanRead method so the correct level of permission is achieved as entities are traversed. You need to be aware that queries can be used to infer data when the entities are not secured. For example, if you have a query that returns the top-paid employees, as shown in Figure 7, the compensation entity that’s accessed to return the Employee data needs to be properly secured so only users who have been granted access can get to this data via the query.

Figure 7 Defining a Query to Return the Top-Paid Employees

Providing a Customized Presentation Experience

Once the data has been secured on the logic tier, it’s time to design the user experience in the presentation tier. If you don’t want a user to have access to a particular screen at all, you can turn the screen off via the <ScreenName>_CanRun method for the application. When a user doesn’t have access to a given screen, the screen won’t show in her navigation menu. You can also restrict commands on a screen by using the 
<CommandName>_CanExecute method.

There are several other methods available on screens and entities that can be used to hide, show and control the editable state of specific controls on a screen, such as <EntityProperty>_IsReadOnly, <ScreenControl>.IsEnabled, <ScreenControl>.IsReadOnly and <ScreenControl>.IsVisible. While the main purpose of these methods is not access control, they’re quite useful in delivering the desired user experience. In some cases, it might be best to hide data users can’t manipulate; other times you may want to show read-only controls; and sometimes you’ll want to guide users to enter data correctly and give meaningful errors if they go astray. The LightSwitch presentation tier allows all this flexibility.

It should be clearly understood that providing logic on the screen to hide, show or control the editable state of data does not protect data from user access; it only controls how the data is displayed. A malicious, authenticated user could potentially hit the logic-tier service directly to view or manipulate data if it’s not secured appropriately. That’s why it’s vital to implement access control on each application tier appropriately.

Securing Data on the Storage Tier

The storage tier is where your data is stored in a database. You can control access to the data in the storage tier by providing a database login with the minimum necessary privileges on the database. The application uses this login to connect to the database and carry out the necessary operations. All connectivity to the data is done via the middle tier, and end users never have direct access to the data or connection string in a three-tier deployment. When you’re deploying a LightSwitch application, you must specify a connection string that the application will use to access the data, as shown in Figure 8. If a unique database login doesn’t exist for the application, LightSwitch will guide the application administrator to create one. It’s highly recommended that the database user identified be specific to the application and be given access only to the pertinent data used by the application.

Figure 8 Specifying the Database Connection Credentials for the Running Application During Deployment

It’s worth mentioning that it’s possible to deploy a secure LightSwitch application with a two-tier deployment. In a two-tier deployment, the presentation tier and the logic tier run on the user’s desktop. This configuration gives the user of the client access to the web.config file where the connection string for the database is stored, therefore it does not offer the separation of presentation and logic tiers required to achieve a secure application configuration. With the connection string, the user can gain direct access to the database and bypass any access-control logic on the middle tier. It’s best to use Windows authentication between the middle tier and the database in this case. Otherwise, a three-tier deployment is necessary to secure the application appropriately.

Deployment Considerations for Access Control

When deploying a LightSwitch application for the first time, you need to create a LightSwitch administrative user. Initially, this is the only user who will have administrator permissions. This user will then be used to configure roles and users within the client application as discussed earlier. Note that this user will be an administrator of your LightSwitch application, but need not be a Windows administrator. A command-line utility is also available to create a new administrative user outside of the deployment process. You can find this utility, Microsoft.LightSwitch.SecurityAdmin.exe, in the LightSwitch install directory.

Leveraging Access-Control Features in IIS

Now that we’ve discussed LightSwitch-specific access-control functionality, let’s briefly touch on some additional ways an application administrator can manually secure LightSwitch applications using the supporting technologies.

LightSwitch and SSL Like Web browsers and Web servers, LightSwitch clients and servers communicate via the HTTP protocol. HTTP specifies that data be sent in clear text, which means that a network eavesdropper could monitor the data the clients and servers exchange. To secure communications against network eavesdroppers, you should instead use the HTTPS protocol, which hides the normal HTTP data in an encrypted tunnel.

LightSwitch applications can be deployed such that clients communicate with the server via HTTPS. This protects not only the sensitive business data that’s exchanged between client and server, but also usernames and passwords when using Forms authentication. It’s a best practice to deploy to an HTTPS site when using Forms authentication in conjunction with IIS or Azure. Otherwise, it’s possible for an attacker to steal the authentication token and impersonate the logged-in user. When using Windows authentication, an attacker can’t recover user passwords or impersonate users, even when using HTTP instead of HTTPS. However, regardless of authentication mode, business data transferred between client and server is still subject to eavesdropping unless HTTPS is employed.

SSL and Certificates Web servers that communicate via HTTPS rely on a server certificate being installed. The certificate serves two purposes. First, the certificate verifies that the server the client is connecting to is actually the correct server and hasn’t been replaced or tampered with. Second, the server certificate contains the secret key information used to encrypt any data sent to the client.

For a Web browser to be able to trust the identity of a server it hasn’t contacted previously, the server’s certificate must have been cryptographically signed by a trusted certificate authority (CA). You can purchase a certificate from a number of providers, such as verisign.com, entrust.net, instantssl.com or geocerts.com. Because most providers charge to generate or sign server certificates, it’s common in development environments to use a self-generated, unsigned—and thus untrusted—certificate.

If you connect to a LightSwitch Web application via HTTPS and the server is using an untrusted certificate, the behavior depends on your Web browser. Minimally, your browser will inform you of the certificate problem and ask if you’d like to proceed. For LightSwitch Web applications, this should work correctly.

However, if you’re using a LightSwitch desktop application that’s hosted by IIS, and accessing it via HTTPS, the IIS server must be using a trusted certificate. Silverlight will not allow desktop applications to come from untrusted server certificates. An untrusted certificate will result in an application that appears to install successfully but will fail immediately upon launch. To remedy this problem, either force your Web browser to trust the server’s certificate by pre-installing it in the client’s certificate store or replace the server’s certificate with one that has been signed by a trusted CA. Note that you’ll want to perform one of these corrective steps before accessing the application for the first time from a given client; otherwise, it will appear to that client as though the certificate has changed or been tampered with.

IIS No LightSwitch-specific configuration is required on the IIS server in order to host LightSwitch applications with SSL. Server administrators should configure the Web server to enable HTTPS, and select a certificate in the normal fashion.

It’s actually possible to host the same LightSwitch application using both HTTP and HTTPS, and there are some situations where you might want to do this. But note that, as already mentioned, any clients that connect via HTTP are not protecting user password information or sensitive business data.

By default, in recent versions of IIS, the Default Web Site listens for both HTTP and HTTPS connections. The server administrator can force a LightSwitch application deployed to such a server to require HTTPS and redirect any HTTP incoming connections to the HTTPS endpoint. This setting is in the web.config of the LightSwitch application.

Application Pool Configuration When publishing to IIS, consider running the application in its own application pool. Application pools provide isolation between worker processes (so if one Web application crashes it doesn’t affect other applications on the server), but they also allow the application to run under different identities. Thus you can create an application pool that hosts a Web application or a set of services that runs under a specific Windows identity and allow access only to the resources that identity needs to run the application. In the case of a LightSwitch application, that additional resource will be the database. By default, the deployment wizard publishes the application under the ASP.NET 4 application pool that runs under a machine account identity. However, this identity doesn’t have access to the application database, so running the application results in an error message such as “Login failed for user ‘IIS APPPOOL\ASP.NET v4.0.’”

There are a couple of options here. If you’re using a SQL Server username/password in the connection string, the application is most likely ready to go (as long as that user had appropriate access to the database). However, when Windows authentication is preferred to connect to the database, a separate application pool is necessary so it can be configured to run under a least-privileged Windows user account. This account must also be granted appropriate access to the application database.

If you’re using Windows authentication in IIS 7, there’s one additional configuration setting of which you should be aware. When you use a custom user identity as the application pool identity, you need to either use the Windows NT LAN Manager (NTLM) provider (not Kerberos) or enable support for Kerberos authentication. Another option is to use the Network Service identity as the app pool’s identity and add that account access to the database instead.

Securing LightSwitch Azure Applications

All LightSwitch applications that are hosted in Azure are publicly accessible. Therefore, these applications have a unique set of access-control requirements.

SSL Encryption LightSwitch will default to using an HTTPS endpoint when publishing an application to Azure. This is to ensure that any sensitive business information is encrypted as it’s communicated over the Internet. LightSwitch provides an option to create a self-signed SSL certificate for the application during publish. While this is a great way to test the application in Azure, it’s highly recommended that a licensed certificate from an external vendor be used, as noted earlier. Because desktop applications won’t work over SSL with an untrusted certificate, you can turn SSL encryption off for debugging purposes by updating the deployment configuration value of Microsoft.LightSwitch.RequireEncryption to false, using the Azure portal to do so after the application has been successfully deployed.

Once the application has been tested using a self-signed SSL certificate, you can update the SSL certificate without republishing the application via the Azure portal. A new SSL certificate can be uploaded for the hosted application by changing the SSLCertificate value to the thumbprint for the newer certificate and turning encryption back on.

Application Authentication Forms authentication is recommended to prevent unauthorized access to Azure-hosted LightSwitch applications. This requires no 
additional server configuration after an application has been published. If the application requires Windows authentication, though, the published LightSwitch application will need to be domain-joined. This requires the use of Azure Connect. You’ll find guidance on enabling Azure Connect at bit.ly/qx0Z6n.

SQL Azure Database Security LightSwitch 
applications will typically rely on a SQL Azure database for their built-in database. This database is necessary if you’ve created any tables in LightSwitch or are using authentication. SQL Azure uses the combination of a firewall and user credentials to protect against unauthorized access.

To allow Azure-hosted LightSwitch applications to connect to the database, the “Allow other Azure services to access this server” firewall rule must be set to true. LightSwitch also requires that a firewall rule be added for the IP address of the machine publishing the application. It’s recommended that this firewall rule be removed once the application has been published. This will prevent any external machines from accessing the database.

Wrapping Up

LightSwitch helps developers build business applications in a simple and productive manner, and this holds true for implementing access-control features as well. Developers can quickly and easily restrict access to their applications through the use of authentication. When more granular control is needed, authorization features provide a powerful way to define permissions and secure assets at the logic and data tiers of the application to effectively control user access. Commonly used features in IIS and Azure can be leveraged for a full access-control solution. The innovation, however, is up to you! Look for more from the LightSwitch team at blogs.msdn.com/b/lightswitch.

Valerie Andersen is a Microsoft program manager working on Visual Studio LightSwitch. Her aim is to drive features into LightSwitch that will enable real-world developers to swiftly build secure, quality applications to meet the needs of customers worldwide.

Matt Evans is a software tester working on LightSwitch. He wants to make sure that your LightSwitch apps are as secure as you need them to be.

Sheel Shah is a Microsoft program manager working on LightSwitch. His focus on the team includes designing Azure support, deployment and LightSwitch client features.

Michael Simons is a senior Microsoft developer working on LightSwitch. His focus on the team is developing data and security features.

Thanks to the following technical experts for reviewing this article: Dan Leeaphon, John Rivard, Dan Seefeldt and Matt Thalman