State driven security (part1) in LightSwitch


Many line of business applications have a notion of workflow state where security aspects are key. The design and maintenance of such an application can become soon complex. Nonetheless, it’s perfectly doable (and maintainable)  in LightSwitch.

Given the importance of this subject, we’ll only introduce in this post a real live example which we’ll use in the next post(s).

We’ll focus in this example app on the security aspects of the states and their transitions. It’s clear that in a normal app, other security aspects matter as well but in order to not overload the app, we’ll simply make abstraction of the other security aspects.

This post is the start of a series:

  • part 1 : this post

  • part 2 : the big picture
  • part 3 : state transition security (server side)

  • part 4 : state transition security (client)

  • part 5 : state driven can do update behavior (server side)

  • part 6 : state driven can do update behavior (client side)

The setting: an holiday approval app

We’ll use deliberately the simple setting of an holiday approval application. Everyone will understand the logic involved and can easily transpose the business logic to their own potentially more complex situation.

What’s the general idea of the application?

Employees can make a request for a day off which can be first “commented’ by their co-workers for a limited period of time. The management assistant will afterwards submit the request to the management  in such a way it can be finally approved or rejected.

The state transition table

When state matters, a “state transition table” is typically the instrument to describe the various aspects and concerns of the application. Let’s first take a look at the state table for our application and then describe step by step the logic that we want to implement:


Our application will eventually treat a holiday request from different perspective (call it: roles):

  • Employee
  • Management assistant
  • Manager

Obviously, an application should never depend on the definition of roles. We’ll make use of the permission mechanism available in LightSwitch and define a role as a container for a group of permissions.

In the above state transition diagram, we get an in compact way on overview of:

  • the states involved
  • the potential transitions between the states
  • the condition under which the transition may be executed.

The state transition diagram is restrictive: transitions which are not on the diagram or prohibited. Transitions which are on the diagram “can” be allowed based on one or more conditions.

Let’s go “epic” now:

  • An employee can create a new holiday request. The system will enforce that this request gets automatically the state “Draft”. No other state should be possible upon creation of a new holiday request.
  • When a new holiday request is correctly saved, the employee can change the state to “Open for Comment”. By doing so, co-workers can, for a limited period of time, provide comments on the holiday request.  While the request is in state “Open for comment”, no one can alter the details of the holiday request.
  • Based on the comments the employee can decide to put the holiday request back in state draft and alter the details of the holiday request. Obviously, he can also decide to leave it in state “Open for comment”.
  • After a certain period, the management assistant will change the state to “Open for approval”. Only the management assistant can do this. Since this is a manual process, sometimes mistakes can be made, so a state transition back to “Open for comment” is possible as well.
  • Holiday requests which are in state “Open for approval”, can be picked up by the manager. She can either approve or reject the request.

What level of security do we want?

We want the the flow of an holiday request is always following exactly the permitted transitions on the state transition table. Nothing more, nothing less.

What level of flexibility do we want?

Well, I must admit, I’ll tweak the answer here to a level of flexibility which is from a pragmatic (my blog is called Pragma Switch for good reasons)  point of view feasible.  So let’s first start by defining which level of flexibility I don’t need or want:

Although from a technological perspective very tempting to design and implement, it will not be possible to “draw your own state machine” inside the application.  It’s all a matter of costs/benefits.

I can live with the fact that if there is a change in the amount of states and the allowed transitions, that I have to recompile and redeploy the application, but what I don’t want either is that such a change would require heavy code writing effort.

The reason why I take this pragmatic position is that, especially with LightSwitch the cost of redeploying an app is very low, but on the other hand I don’t want that states and transitions are living hard coded inside the app.

Ok, without getting in this first post about the subject already too technical:  I can live with the fact that a change to my state transition table would boil down to an update of the permission table of the application and an update to the content of a specific state table in the database.

What’s next?

The implementation of the above, what else !