Compartilhar via


How to: Enable Authentication in a Silverlight Client App

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.

Note

The process for setting permissions differs for HTML clients – see How to: Enable Authentication in an HTML Client App. LightSwitch apps that have been enabled for SharePoint use SharePoint authentication for access control.

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

  1. In Solution Explorer, open the shortcut menu for the Properties node, and then choose Open.

  2. In the Application Designer, choose the Access Control tab.

  3. 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

  1. In Solution Explorer, open the shortcut menu for the Properties node, and then choose Open.

  2. In the Application Designer, choose the Access Control tab.

  3. 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

  1. In Solution Explorer, open the shortcut menu for the Properties node, and then choose Open.

  2. In the Application Designer, choose the Access Control tab.

  3. 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.

  4. 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.

  5. In the Description column, enter a description of the permission.

To write code to set permissions for a screen

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

    The Screen Designer for that screen opens.

  2. In the Write Code list, choose CanRunScreenName, where ScreenName is the name of the selected screen.

  3. In the Code Editor, enter the following code in the CanRunScreenName method:

    If Application.User.HasPermission(Can_View_Products) Then
        result =  True
    Else
        result = False
    End If
    
    if (Application.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. Replace the name of a permission that you have defined in your application.

To write code to set permissions for a command

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

    The Screen Designer for that screen opens.

  2. In the Screen Content Tree pane, expand a command node, and then choose the command for which you want to write code.

  3. Open the shortcut menu for the command, and then choose ButtonName**_CanExecute**, where ButtonName is the name of the command that you chose.

  4. 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

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

    The Entity Designer for that entity opens.

  2. In the Entity Designer, on the Perspective bar, choose Server.

  3. 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.

  4. 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

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

    The Query Designer for that query opens.

  2. In the Write Code list, choose one of the QueryName**_CanExecute** methods, where QueryName is the name of the query.

  3. 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

  1. In Solution Explorer, open the shortcut menu for the Properties node, and then choose Open.

  2. In the Application Designer, choose the Access Control tab.

  3. 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 and Administration

The final step in enabling authentication is to define a default administrator for the application during publishing. Once published, the default administrator must log in and define users, roles and permissions.

To define an administrator

  • Follow the steps in Administering a LightSwitch Application.

    Important

    If authentication is enabled and you haven’t defined a default administrator, you won’t be able to access the published application.

See Also

Tasks

Administering a LightSwitch Application

How to: Enable Authentication in an HTML Client App

Concepts

Security Considerations for LightSwitch

Other Resources

Silverlight Client Screens for LightSwitch Apps

Active Directory Security Groups