Using a dedicated security database for multiple LightSwitch apps. (Part 1)

Introduction

Before we tackle the real subject of this blog post, we need some kind of primer on LightSwitch Security and in particular on the notion of “permissions”.

By default, LightSwitch incorporates in its intrinsic database the necessary tables (and stored procedures) for managing users, members and roles. The structure of these tables is based on (but is not identical to) the classical ASP.NET Membership Security Database, which can be generated by aspnet_regsql.exe (to be found in the .NET framework folder).

Permissions in LightSwitch

Authorizations in LightSwitch are based on “permission”, which goes very elegantly together with MVVM-based approach of Commands. An example will clarify. Imagine, I want to only allow certain users to add a new customer. Rather than directly linking this “feature” to a specific role we introduce a level of indirection, namely the permission “CanAddCustomer”. Afterwards we can freely assign this permission to a specific role (e.g. ‘CustomerAdministrator’). We can manage the application permissions in the access control tab of the application properties:

Afterwards, this permissions can be used (strongly typed !) in the applicable _CanExecute method of the Command where the permission is used:

public partial class CustomersListDetail

    {
        partial void CustomerListAddAndEditNew_CanExecute(ref bool result)
        {
            result = this.Application.User.HasPermission(Permissions.CanAddCustomer);
            //result = this.Application.User.IsInRole("MyRole"); //sub-optimal
        }

        partial void CustomerListAddAndEditNew_Execute()
        {
            // ...
        }

    }

 

The above code snippet contains as well the sub-optimal way of using directly the role. The reason why it’s sub-optimal is because we are not making using of the indirection that permissions provides us. The functionality of adding a customer is now strongly linked to a specific role. If we would use the permission, we could afterwards easily assign or remove the permissions to multiple roles.

Where are my Permissions in the LightSwitch app ?

The set of available permissions are stored in the ApplicationDefinition.lsml file:

<Permission Name="CanAddCustomer">

    <Permission.Attributes>

      <DisplayName Value="Can Add Customer" />

      <Description Value="Provides the ability to add a customer." />

    </Permission.Attributes>

  </Permission>

The Lightswitch magic does not only make them available strongly-typed in the application, but they become also available as selectable item in the Administration screens of the application when we want to setup a role (i.e. assign a set of permissions to a role):

Where are my permissions in the database?

In the LightSwitch database, the mapping between roles and permissions is stored in the RolePermissions table. This table does not use technical Ids (so no referential integrity here), but has only two string fields: RoleName and PermissionId.  PermissionId could suggest that it is a technical Id, but it’s the string representation of the permission defined in the LightSwitch application prefixed with “LightSwitchApplication:” (in my example: LightSwitchApplication:CanAddCustomer).

OK, all this for setting the foundation for my real subject of this series of posts: how can we separate the security tables from our LightSwitch application database.