Part 5 already of our series on Visual Studio LightSwitch 2010! Now that we have a solid understanding of how we can build applications in LightSwitch, based on data, queries and screens, we have arrived at a point where we have to start asking questions like “Can each user access each screen?”, “How can I change permissions within my application” and “How do I get my application on the client’s machine?”. These are all valid questions that pop into a developer’s mind during the development of any application. In this article, we’ll tackle security and deployment topics.
The code for this article can be downloaded here.
Making your LightSwitch applications secure
LightSwitch has a built-in system that allows us to manage security at a fine-grained level. This system is a combination of authentication and permission-checking (authorization). Part of this can be set through a screen in the properties (see screenshot below). On the other hand, we can also check permissions from code. Let’s take a look.
Authentication
Authentication is a process where the application checks who is accessing it. Based on the passed-in data (usually in the form of a username/password combination), the user will be granted access to the application. When we create a new LightSwitch, authentication is disabled by default. This effectively means that the application, when deployed, can be opened by every user that wants to use it and each operation and screen within the application is available as well. The above screenshot of the Access Control tab (Properties à Access Control) shows that by default, the “Do Not Enable Authentication” is checked.
Other options that are available are Windows Authentication and Forms Authentication. When using Windows authentication, we get access to the user token that’s authenticated in Windows. If we want to use Forms authentication, the user will need to supply a username/password combination, similar to Forms authentication in an ASP.NET application. We’ll see further how we can use these.
Permissions
Without us asking, LightSwitch generates an entire system of access control methods along with the generated code. Methods are generated for screens, data, queries… This results in the ability to check whether a user can view a certain screen, if he/she can perform a save on a certain entity… We can hook into these methods and write code to check this. This system is based on permissions. Permissions are the lowest level of rights that the user can have within the application. We can define permissions and check whether or not a user has the permission.
Users and roles
In most applications, users aren’t given permissions directly. Instead, they are grouped in roles. In LightSwitch, this is exactly the same. The basic thought behind this is that the task of managing permissions for individual users would be too tedious to do (imagine you being the administrator to manage permissions per user on a day your company has hired 30 new people…!) We’ll soon see how we can create these roles and assign permissions thereon.
Applying security
Now that we know what security options are available, let’s take a look at how we can apply them together.
In MoviePolis, we identify 2 roles. One group manages the movies, show times, distributors and the rooms, while another group is responsible for ticket sales. A third role, the system administrator, has access to all functions and also manages the security in the application. This role is built-in in the application and is the one used by default when developing the application.
With the MoviePolis solution open, go to the Access Control tab. In here, select Windows authentication for now and notice that the permissions grid becomes editable. In this grid, add the following permissions:
- CanManageRooms
- CanManageMovies
- CanSellTickets
Note the Granted for Debug checkbox in each row. When checked, the role is automatically granted when running the application from the debugger. This frees us from having to deal with logins during the development of the application.
We can now write code inside the access control methods that will check whether a user has a certain permission. The EditableMoviesGrid screen, used to manage the Movies, is only accessible for user in the role where the CanManageRooms permission is true. To check this, open this screen in the designer, click the Write code button and select the EditableMoviesGrid_CanRun method.
In the code, we can now check this permission as follows:
partial void EditableMoviesGrid_CanRun(ref bool result)
{
result = User.HasPermission(Permissions.CanManageMovies);
}
If we run the application now, we won’t see any difference. However, if we uncheck the “Granted for debug” checkbox, we can see that the screen won’t turn up in the list of available actions, as shown below.
The other screens are similar.
We can also use these permissions in other places. For example, assume that we have another permission, CanDeleteMovies. Users that don’t have this permissions, can see the screen, view the data but can’t delete movies. LightSwitch generates quite a few access control methods for the data as well, as shown below.
We can check the permission using the following code:
partial void Movies_CanDelete(ref bool result)
{
result = Application.Current.User.HasPermission(Permissions.CanDeleteMovies);
}
The result is shown below, where the delete button is disabled.
Managing the users and the roles
So far, we have been playing around with the checkbox to grant a permission in debug mode. Of course, we need a way to manage users and manage the permissions for the roles. Screens for this are built-in with LightSwitch, we don’t have to create them ourselves. Let’s take a look.
When deploying the application (we’ll look at deployment options later in this article) and running the installed version as the system administrator, a new Administration item appears with two subitems, Roles and Users. As can be deducted, the screens will allow the administrator to manage the roles and the allowed users. The application developer need not to worry about building these himself.
In the Roles screen, we can define the roles for our application.
For each role, we can then add the permissions (all permissions defined in the application are available through a dropdown selection).
Finally, we can add users to the role.
Note that if we take Windows authentication and only one user is available, with default settings, this user will become the administrator and can’t be added to another role.
The user screen gives us about the same data, but from a User management point-of-view.
Windows and Forms authentication
In the above sample, we used the easiest approach, where we used the built-in Windows authentication to manage the users. Let’s look at how we can work with Forms authentication, so that the user will have to log in to the application.
From the Access Control tab, select Forms authentication.
Deploy the application through the Publish wizard (again, we’ll look in more details at this in the Deployment section). Follow these screenshots for the deployment options.
Select Desktop for the type of application you want to create.
Select Local for where the services will be hosted.
You can choose where you want the output to be placed.
You can define where the database should go (you can leave the default options):
Define the administrator for the application. This user will get access to the administration screens.
In the other screens, just select the default. Finish the deployment wizard by hitting the Publish button. Visual Studio will now generate an *.msi (installer) file for you, located in the Publish location. Install this file and run the application.
We are now presented with a login screen.
We can now create new users and assign them to roles.
Each user will be presented with the login screen. Based on the user name, specific functions or screens will be available.
We have now already had an introduction to deployment. Time to learn more about it!
Deployment
Building an application on a single machine is one thing. A vital ingredient of developing applications is getting the application is the user’s hands (or at least on his machine J).
To deploy applications, LightSwitch has a wizard that guides us through the process of creating redistributable packages of our applications. This wizard will guide us through the different deployment options offered by LightSwitch. Keep in mind that we don’t have to worry about deployment during the development. In all cases, we are building the same (Silverlight) application that will be deployed on the desktop or run from within the browser.
Deployment options
LightSwitch applications are essentially 3-tier applications. However, we don’t have to physically use 3 machines to run a LightSwitch application! Instead, we can choose to run everything from the same machine if we want to. To make this distinction, LightSwitch offers several ways for deployment of both the client and the server tier.
On the client, we have:
- Web/browser: the application will run as a Silverlight in-browser application. This may be easier when deploying inside an enterprise since users don’t have to perform an installation. However, since we are running Silverlight inside the browser, some functionality such as Excel export won’t work.
- Desktop: in this case, the application is installed as a Silverlight out-of-browser application, running with elevated trust.
On the server-side, we can have:
- Client machine: the server components and the database are installed on the same machine
- IIS: the server components are installed in IIS on a webserver, the database may be on a different server.
- Windows Azure: LightSwitch applications can be installed in Azure. Several building blocks of Azure are required. If using Azure, we of course need an Azure subscription. We need a hosted service where the server components will be hosted (this is basically a service in the cloud). A storage account is required as well. Finally, we can host the database in SQL Azure.
The full installation on Azure can be found here: http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k(LS.SERVERCONFIGURATION)&rd=true .
When using IIS or Azure, the client-side is just a thin layer.
Deployment Configuration
Once you know which way you’ll be going with your LightSwitch application, you can make your selections in the project properties. Once you’re ready, you can use the Publish button in this screen (or alternatively, right-click on the project and select Publish) and the LightSwitch Publish Application Wizard will start. We’ve seen this wizard already before, so I won’t be stepping through all the steps again.
Note that one single application can be installed in several ways. You can run the publish wizard several times with different settings (once cloud, once desktop). Any LightSwitch application can be installed in all above-mentioned deployment configurations, there’s no need to keep deployment options in mind while developing the application itself.
Summary
In this part, we’ve covered two topics, security and deployment. We’ve seen how we can create applications that manage users, roles and permissions and looked at the different available authentication options, Forms and Windows authentication. In the deployment part, we’ve look at the different options that LightSwitch offers to deploy an application.
In the next part, we’ll start looking at how we can extend LightSwitch. Stay tuned!
About Gill Cleeren
Gill Cleeren is Microsoft Regional Director (www.theregion.com), Silverlight MVP (former ASP.NET MVP), INETA speaker bureau member and Silverlight Insider. He lives in Belgium where he works as .NET architect at Ordina. Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd Berlin 2010, TechDays Belgium, DevDays NL, NDC Oslo Norway, SQL Server Saturday Switzerland, Spring Conference UK, Silverlight Roadshow in Sweden… He’s also the author of many articles in various developer magazines and for SilverlightShow.net. He organizes the yearly Community Day event in Belgium.
He also leads Visug (www.visug.be), the largest .NET user group in Belgium. Gill recently published his first book: “Silverlight 4 Data and Services Cookbook” (Packt Publishing). You can find his blog at www.snowball.be.
Twitter: @gillcleeren