State driven security in LightSwitch (part2): the big picture


Let’s try to summarize what we will cover in this series about state driven security. Let’s first answer the question “what is state” and try to come up with a potential approach to handle state driven security in LightSwitch.




What is State?

State allows us to put a kind of “label” on an object in such a way we, in the context of security, apply discrete decisions on the handling of the involved workflow on the object.

What are the “discrete” decisions we want to cover?

  • the potential state transitions: the above pictures provides an overview of the allowed transitions.
  • the state transition user management: who can do transition xyz?
  • the effect of state on the “crud”-capabilities of the object (and the related object graph) which is monitored by the state.


The above gives room for a whole range of potential approaches from very simple to very sophisticated. This blog is about LightSwitch and I want to keep things simple and leverage as much as possible the goodness of LightSwitch.

This will mean among others,  that I’ll use the build-in permission mechanism of LightSwitch: the “mediator” between the user’s role and the security protection of application artefacts in code.

The data model of our sample app

Deliberately simple, only focusing on the logic I’ll demonstrate in this series of posts:

We have a holiday request entity:


So, a holiday request has some string fields and an attached entity called HolidayRequestManagement feedback via a 1 to 0..1 relationship:


The idea of the 1 to 0..1 relationship is to be able to protect the HolidayRequestManagementFeedback fields also in a state driven way, i.e. given a certain state the fields can or can not be updated.

The most important field in the HolidayRequest is of course the HolidayStateCode which is of type StateCode:


The StateCode entity has 2 fields: StateValue (e.g. Draft, Rejected, …) and a boolean property IsInitialState.


Our state value is in a dedicated table which implements an Interface IStateValue.

 public interface IStateCode : IEntityObject
        string StateValue { get; }
        bool IsInitialState { get; }


Why are we not using the LightSwitch choice lists here? Well, I have considered various options, but the approach with a dedicated table in which are we store the lists of potential states allows us the provide also a very good client side experience for the state transition management: we can apply a filter on the potential states (this would not be possible. That gives a lot of user comfort. For example: given the fact we are in state draft, the list of potential states are “Draft, Open For Comment”. That would not be possible with choice lists.

Obviously, our StateCode table needs to implement the IStateCode interface:

public partial class StateCode :IStateCode


For the rest I do not make any data model related assumptions for the low level infrastructure of the state management security. The state itself can be everywhere: either inside the entity which is monitored by the state value or in another table in the object graph of the monitored entity. In our example implementation, the state code is directly in the HolidayRequest Entity, but as said, that’s not mandatory, nothing should prevent me from storing the state for example in a child table (with a 1 to 0..1 relationship) of HolidayRequest.

So, when we speak about StateCode we mean the state object, the State value refers to the value (the StateValue field) in the table that implements IStateCode.


What’s next?

  • The next post part 3) will be completely dedicated to the validation of the state transitions: given a current state of the holiday request, the user will be allowed to move or not move the holiday request to another state. 
  • Part 4 will add some client side state transition convenience (i.e. avoid that the user can select non appropriate state transitions), both in a silverlight and an html client.
  • Part 5 will be dedicated to the modification rights of the holiday request given the current state of the request. Also the modification rights of related entities (in our case the HolidayRequestManagementFeedback entity) will be in scope.
  • Part 6 will cover the client side (silverlight and html) of state based modification tracking.

If you think you can’t do this with LightSwitch then think again.