LightSwitch Authentication and Authorization

Article
11/19/2013

In LightSwitch, you can make your application more secure by preventing unauthorized users from reading, changing, or deleting data. If you implement authentication and authorization, users must prove their identities before they can access the application. If you have many users, you can also manage access more easily by creating user roles that have various levels of access to particular screens and data and then assigning each user to the appropriate role.

For example, a payroll application could allow employees to view, but not change, their payroll information. However, a payroll supervisor could be given permission to view and change the employee information. The employees would be assigned to the Employee role and the supervisor would be assigned to the Supervisor role.

You can also administer permissions more easily by adding users to security groups in Active Directory and then assigning permissions to those groups. Because membership and permissions are inherited, you can grant and deny permissions for not only a group but also all of its subgroups by making a single change. For example, you can add Bob to the Sales group in Active Directory. If Sales is a subgroup of Marketing, any permission that you grant to Marketing would also be granted to Bob.

Authentication

The first step in securing your application is to enable authentication. You can use either Forms authentication or Windows authentication. Forms authentication is managed by the application itself, and a user must supply a username and a password to access the application. In Windows authentication, the credentials that were used to log on to the computer where the application is run are used to authenticate the application user, and no additional username or password is required. In both cases, an application administrator maintains a list of authorized users; in Forms authentication, the administrator also maintains encrypted passwords.

To enable authentication

In Solution Explorer, open the shortcut menu for the Properties node, and then choose Open.
In the Application Designer, choose the Access Control tab.
In the Select the type of authentication to use: list, choose either Use Windows authentication or Use Forms authentication.

If you chose Use Windows authentication, choose either the Allow only users specified in the Users screen of your application option button or the Allow any authenticated Windows user option button.

The application will now require users to provide credentials in order to access the application.

To disable authentication

In Solution Explorer, open the shortcut menu for the Properties node, and then choose Open.
In the Application Designer, choose the Access Control tab.
In the Select the type of authentication to use: list, choose Do not enable authentication.

The application will not require users to provide credentials in order to access the application, and any user can access every part of the application.

Permissions

The next step in securing your application is to create permissions. You can define permissions for screens, commands, data entities, and queries. First, define a permission object in the Application Designer. Then, you can reference the object in code, in one of the Can methods such as CanRun<ScreenName> or <QueryName>_CanExecute. Code in these methods typically checks whether the current user or role has the permission, and then displays the form or executes the query only if permission is validated.

To test your code, run the application as both a user who has the permission and as a user who does not. By setting debug permissions, you can impersonate a user when you test or debug the application.

To create a permission

In Solution Explorer, open the shortcut menu for the Properties node, and then choose Open.
In the Application Designer, choose the Access Control tab.
In the Define permissions or select permissions to use for debugging grid, in the Name column, choose <Add New Permission>, and then enter a programmatic name for the permission.

The name must begin with an alphabetical character, and it can only contain alphabetical or numeric characters, or underscores.
In the Display Name column, enter the name of the permission as you want it to appear in the screen that the application administrator will use to assign roles.
In the Description column, enter a description of the permission.

To write code to set permissions for a screen

In Solution Explorer, open the shortcut menu for a screen node, and then choose Open.

The Screen Designer for that screen opens.
In the Write Code list, choose CanRunScreenName, where ScreenName is the name of the selected screen.
In the Code Editor, enter the following code in the CanRunScreenName method:
```
If Current.User.HasPermission(Can_View_Products) Then
    result =  True
Else
    result = False
End If
```
```
if (Current.User.HasPermission(Permissions.Can_View_Products)) 
{
    result = true;
} 
else 
{
    result = false;
}
```
This code will be evaluated every time that the application starts.

Note

Notice that the example code checks for a permission named Can_View_Products. Wherever it appears, substitute the name of a permission that you have defined in your application.

To write code to set permissions for a command

In Solution Explorer, open the shortcut menu for a screen node, and then choose Open.

The Screen Designer for that screen opens.
In the Screen Content Tree pane, expand a command node, and then choose the command for which you want to write code.
Open the shortcut menu for the command, and then choose ButtonName**_CanExecute**, where ButtonName is the name of the command that you chose.
In the Code Editor, enter the code that you want in the ButtonName**_CanExecute** method.

Note

For an example of code, see "To write code to set permissions for a screen" earlier in this topic.

To write code to set permissions for an entity

In Solution Explorer, open the shortcut menu for an entity node, and then choose Open.

The Entity Designer for that entity opens.
In the Write Code list, choose an EntityName**_Can**Operation method, where EntityName is the name of the entity, and Operation is the name of the operation for which you want to write code.

Note

The available methods vary by context. Some examples are CanDelete and CanUpdate.
In the Code Editor, enter the code that you want in the EntityName**_Can**Operation method.

Note

For an example of code, see "To write code to set permissions for a screen" earlier in this topic.

To write code to set permissions for a query

In Solution Explorer, open the shortcut menu for a query node, and then choose Open.

The Query Designer for that query opens.
In the Write Code list, choose one of the QueryName**_CanExecute** methods, where QueryName is the name of the query.
In the Code Editor, enter the code that you want in the QueryName**_CanExecute** method.

Note

For an example of code, see "To write code to set permissions for a screen" earlier in this topic.

To enable permissions for debugging

In Solution Explorer, open the shortcut menu for the Properties node, and then choose Open.
In the Application Designer, choose the Access Control tab.
In the Define permissions or select permissions to use for debugging grid, choose the permission that you want to enable for debugging, and then select the Granted for debug check box.

Publishing

When you help secure your application, the final step is to publish it. When you publish for the first time, you must provide authentication information for a default administrator. When you publish again, you don’t have to repeat this step.

To provide authentication information when you publish an application

In the LightSwitch Publish Application Wizard, choose the Security Settings page, and then choose the Yes, create an Application Administrator option button.

Note

You must perform the remaining steps only if you’re publishing directly to a server. If you’re creating a package, you will be prompted to add an administrative account when you deploy the package.
In the User Name text box, enter a username.

If you’re using Windows authentication, you must specify a valid Windows logon name that has the form Domain\Username.

Tip

You can also assign a security group in Active Directory as the default administrator.
In the Full Name text box, enter the full name of the user or group that will be the default administrator.
In the Password text box, enter a password.

Note

If you’re using Windows authentication, the Full Name, Password and Confirm Password fields don’t appear.
In the Confirm Password text box, enter the password again.

Remember the username and password because you'll need to specify them the first time that you run the application.
Finish publishing the application.

Roles and Users

If you're the application administrator, you must run the published application the first time. You then use the Roles screen and the Users screen to define roles, assign permissions to the roles, and assign roles to users or groups of users. You can access these screens in the running application at design time or when it’s deployed. At design time, set a debug permission to access the screens. In a deployed application, anyone who has been granted the Security Administration permission can access the screens.

Note

To log on, you must use the username and password that you specified when you published the application.

To define a role and assign permissions

In a published application that’s running under administrator permissions, on the menu bar, choose Roles.
In the Roles pane, choose the +… (Add) button.
In the Add New Role dialog box, enter a name for the role, and then choose the OK button.
In the Permissions pane, choose the +… (Add) button.

A new row appears in the Permissions grid.
In the first column of the grid, choose a permission in the list.

The list contains all of the available permissions for your application. You can add as many permissions as you need, but you must choose the +… (Add) button for each one to add it.
On the application toolbar, choose the Save button to save your changes.

To add a user or group of users

On the menu bar, choose Users to display the Users screen.
In the Users and Groups pane, choose the +… (Add) button.
In the Name text box, enter a username.

If you’re using Windows authentication, you must specify a valid username in the form of an alias (terry), a domain and an alias (example\terry), an alias and a domain (terry@example.com), or a fully qualified domain name and an alias (northamerica.corp.example.com\terry). The entire string must contain fewer than than 256 characters. You can also specify the name of a security group in Active Directory. If you’re using Forms authentication, the username must be unique and contain fewer than 256 characters.
In the Full Name text box, enter the user’s full name.

The information in the Full Name field is used only for display purposes.

Note

For Windows authentication, the Full Name field is automatically populated based on the username and can’t be edited.
In the Password text box, enter a password.

Note

The Password and Confirm Password fields don’t appear if you’re using Windows authentication.
In the Confirm Password text box, enter the same password.
In the Roles pane, choose the Add button, and then choose a role in the Roles list.

You can assign a user to multiple roles by repeating this step for each role.
On the application toolbar, choose the Save button to save the changes.

To remove a user or group of users

On the menu bar, choose Users to display the Users screen.
In the Users and Groups pane, choose the account that you want to remove, and then choose the X (delete) button.

Note

If a user is logged on with an account that’s deleted, the user can no longer save or access data on the server. If the user tries to access data from the server, an Access Denied message appears.

Note

If a group account is deleted, any user whose role was inherited from that group will lose permissions for that role.
On the application toolbar, choose the Save button to save the changes.