A case for server side permission elevation in the LightSwitch retrieve pipeline

Introduction

Since the latest version of LightSwitch using the permission elevation mechanism is also possible in the retrieve pipeline.

You can find a good example of using permission elevation in the save pipeline over here:

DECENTLY PROTECTING ENTITY FIELDS WHICH MAY BE ONLY UPDATED BY SERVER SIDE PROCESSING

I’ll try to answer in this article if there is a use case for permission elevation in the retrieve pipeline.

Using permission elevation in the filter method

Let’s take the simple setup of a customer table and a table containing commercial decision rules (call it: CommercialDecisionTable).

The customer table is protected by row level security rules which are typically programmed in the _Filter() method:

partial void Customers_Filter(ref Expression<Func<Customer, bool>> filter)
        {

            if (this or that condition)
            {
                filter = e=>e... // this or that logic
            }

        }

Let’s say that the Customer table is consumed  normally by business people and the type of logic is: a customer representative may only see her own customers. Now let’s take the case where this logic also depends on information in the CommercialDecisionTable.

The CustomerDecisionTable on the other hand, should never be read by business people (only the management can update and view  this information). So, what we typically do is:

 partial void CommercialDecisionTables_CanRead(ref bool result)
        {
            result = this.Application.User.HasPermission(Permissions.CanReadCustomerDecisionTable);
        }

Ok, now we are very close to our case for permission elevation in the retrieve pipeline:

partial void Customers_Filter(ref Expression<Func<Customer, bool>> filter)
        {
            using (this.Application.User.AddPermissions(Permissions.CanReadCustomerDecisionTable))
            {
                var result = this.CommercialDecisionTables.First().SecretInfo;
                if (result !=null)
                {
                    //apply specfic filter logic based on the knowledge in the commercial decision table
                }
            }
        }

That’s all. The above makes sure that nobody (unless you have the right permission) can read the CommercialDecisionTable information. Notheless, in the retrieve pipeline server side we can still use the information for fine tuning our row level security on the Customer table.

Conclusion

Security can also be simple. As simple as possible but no simpler.