Implementing Access Control on a Visual Studio LightSwitch Application
Alright.. after my previous blogs of looking at Visual Studio LightSwitch from under the hood, a small demo application using Visual Studio LightSwitch, adding a form of implementing a simple workflow with Visual Studio LightSwitch and how cool I thought customizing a Visual Studio LightSwitch application is with the changes during runtime still being in the undo stack at design time, this time I will try to illustrate the answer to an offline question I got about LightSwitch.
“How would one implement roles authentication with Visual Studio LightSwitch? How is Visual Studio LightSwitch and Windows Authentication done, if it can be done and non-Windows Authentication too.”
So I went along and told the person.. I haven’t tried it yet, but I’ll try it for you and blog the result.
So here goes.
First thing that would come to mind was to add a login form, right? But no, it didn’t turn out that way. Then as you go along creating a Visual Studio LightSwitch application, you will get the idea that most of the tasks you perform are adding objects (either entities or screens) and then changing properties. So I tried adding a User entity then creating a screen for that. It didn’t quite work out and I think I found the way.
By looking around and trying stuff I found this
After I right-clicked on the project and chose properties, so I went ahead and clicked the Access Control tab and added a couple of experiments
I highlighted several areas on the screenshot above.
First are the option buttons. Here you will see that Visual Studio LightSwitch does indeed offer not only both Windows Authentication and Forms Authentication but also a disabled authentication mode. So for this blog, I’ll choose Windows Authentication.
Next you will see that I highlighted the descriptions that I added. “on the screen” and “on the entity”
Here I illustrate that Visual Studio LightSwitch can implement access control on both(or either) the Entity or the object that you create, and the Screen.
It is also worth noticing that Visual Studio LIghtSwitch has a default Access Role called SecurityAdministration. That was there when I got there.. so.. that’s the default. Hahahaha!
Okay, so how do you implement these roles now?
Just poke around the IDE and you will find this:
There is actually a stub to place code to set if the patientSearchScreen can be ran!
So I go into that part of the code and..
It takes me to Application.cs, the code for the whole application. Where I insert that line of code.
// Set result to the desired field value
result = this.User.HasPermission(Permissions.canViewPatientScreen);
The CanRunPatientSearchScreen function is a bool function that returns either true or false (of course) so what we do is we set the result, depending on the User object that is logged in to the application.
So there. .we have implemented Access Control on Visual Studio LightSwitch on the screen level. But what about the Entity level that I tried before? You may stop reading this blog for a while and try out the steps yourself by also clicking the “Write Code” drop-down on the Therapist entity and see if the code stubs will be there.
I got me this:
And since the access control role that I declared for this entity is “Can Add Therapist” we should go to the therapists_CanInsert function and add our code there.
Notice the slight difference in code?
Some key things are worth noticing:
- We have now seen how Visual Studio LightSwitch implements Access Control using Windows Authentication.
- Visual Studio LightSwitch allows you to define access control both on the screen level and entity level.
- Visual Studio LightSwitch creates the User and Permissions namespaces for us making it easier to implement access control using Windows Authentication.
Stay tuned for my next blog on how to implement Forms Authentication and adding new Users and setting the roles within Visual Studio LightSwitch.