Using LightSwitch ServerApplicationContext and WebAPI to Get User Permissions

Last post I showed a simple way of checking a single user permission from an HTML client screen in order to disable/enable UI elements. If you only have a couple permissions to check and you don’t want to write a lot of code then this simple tip works. However, if you need to check many permissions throughout your HTML client app or you need to return permissions to custom web clients you build against the LightSwitch server, a better idea is to retrieve all these permissions at once for the logged in user and store them on the client so all screens can access them without hitting the database again.

The LightSwitch philosophy is to provide RAD tools for building business apps fast, but still allow advanced customization where and when you need it. In this post I’ll show you a way to return user permissions by creating a custom web method using Web API and the LightSwitch ServerApplicationContext that was introduced in Visual Studio 2012 Update 2. If you missed Matt’s post about it, check it out here: Using the LightSwitch ServerApplicationContext API

Create Permissions and Secure your Data

The first step in securing your data based on user permissions is to define your permissions and check them from the entity access control methods. For this example, we will define a couple permissions “CanAddCustomer” and “CanEditCustomer” that determines whether a user can perform Inserts and Edits on a Customer entity on the server.

Open the Project Properties and define your permissions. Make sure to enable authentication. Then check off the permissions you want to enable while you’re debugging.

Then in the data designer, select the Server perspective and then drop down the “Write Code” button and select the Customers_CanInsert and Customers_CanUpdate access control methods:

Then you write code like this to allow or disallow the insertion and editing of customers:

VB:

Private Sub Customers_CanInsert(ByRef result As Boolean)
result = Me.Application.User.HasPermission(Permissions.CanAddCustomer)
End Sub
Private Sub Customers_CanUpdate(ByRef result As Boolean)
result = Me.Application.User.HasPermission(Permissions.CanEditCustomer)
End Sub

You always want to secure the server-side this way in order to protect the data in your system. However, sometimes we also want to use a permission check in the UI in order to hide/unhide (or enable/disable) elements on a multitude of screens.

As I mentioned in my previous post, the Silverlight desktop client exposes a User object available to you at all times from any screen, so checking permissions on the client is easy. Here’s how you can create a similar object for the HTML client that holds all the permissions for a logged in user.

Create a Custom Web API on the LightSwitch Server

First we’re going to use Web API to expose a RESTful service that will return JSON to the client. Flip to the file view in the Solution Explorer.

Add a folder called “Perms” (or whatever you want to call it) to the Server project , add an new item, and select Web API Controller Class and name it “UserPermissionsController”.

Now we can use the LightSwitch ServerApplicationContext to verify the user is authenticated and to create a dictionary of their own permissions. If the user is not authenticated then nothing is returned. Note that you will need to add references to the LightSwitch Server and Security namespaces first.

In order to query the LightSwitch SecurityData where the permission data resides we need to temporarily elevate the caller’s permissions. This elevation is only in effect during the extent of the execution of the method. For more information about permission elevation see: How to Elevate Permissions in Server Code

Be careful what you put in this dictionary. Here we are simply populating a list of permissions, we’re not putting any sensitive information in there like the user’s name or passwords. Remember with power comes responsibility.

VB:

Imports System.Net
Imports System.Web.Http
Imports LightSwitchApplication
Imports Microsoft.LightSwitch.Server
Imports Microsoft.LightSwitch.Security
Public Class UserPermissionsController
Inherits ApiController
' GET api/<controller>
Public Function GetValues() As Dictionary(Of String, Boolean)
'This will generically retrieve all the permissions of the current logged in user.
Dim perms As New Dictionary(Of String, Boolean)
Using ctx As ServerApplicationContext = ServerApplicationContext.CreateContext()
Dim currentUser = ctx.Application.User
'If the requestor is not logged in then nothing is returned.
' Only properly logged in users can retrieve their own permissions
If currentUser.IsAuthenticated Then
perms.Add(Permissions.SecurityAdministration,
currentUser.HasPermission(Permissions.SecurityAdministration))
'elevate permissions temporarily
currentUser.AddPermissions(Permissions.SecurityAdministration)
For Each perm As Permission In ctx.DataWorkspace.SecurityData.Permissions()
If perm.Id <> Permissions.SecurityAdministration Then
perms.Add(perm.Id, currentUser.HasPermission(perm.Id))
End If
Next
End If
End Using
Return perms
End Function
End Class

Retrieve the Permissions on the Client

Next we need to call this method from the client and save the data in a global object. On the LightSwitch HTML client there is a global object called myapp that we can use to store the permissions object. You can use the myapp object in a variety of ways in order to access data and screens in the HTML client. Check out some other uses here- How to: Modify an HTML Screen by Using Code

The handiest place to put the code to retrieve the permissions is in the created method on the first screen in our application. This is the first user method that will be called when the app starts and we can be sure that the LightSwitch client environment is ready.

Open the screen that is set as your Home screen (this is probably the first screen you created or you can right-click on a screen in the Solution Explorer and “Set as Home Screen”). Select the Screen node at the top of the content tree, drop down the “Write Code” button, and select the created method.

Here’s the code that will call the web API and return a JSON object with the permissions.

Put a breakpoint here and notice that the dictionary of permissions is returned when you run it.

Check the Permissions in JavaScript Code

Now that we have the set of permissions on the client we can check permissions anywhere in our HTML screens by writing some simple JavaScript. In my example I want to enable/disable buttons on a screen depending on whether the user can add or edit Customers.

First take note of the control names you want to manipulate. In my case I have a couple buttons one named AddCustomer and another named EditCustomer.

Just like before, select the Screen node at the top of the content tree, drop down the “Write Code” button, and select the created method for that screen. Then write code to check the permissions object:

Now we can see that buttons are correctly enabled & disabled based on the permissions.

Wrap Up

LightSwitch is all about productivity and we strive to provide the best developer experience for building business apps as fast as possible. However we also want to allow advanced customization and power where and when you need it. Whether that’s implementing custom controls, data sources, web services, etc. -- there is a lot of room for extensibility, especially in the latest version (V3) of LightSwitch in Visual Studio 2012 Update 2.

There are a lot of possibilities that are available to you now that we’ve opened up the LightSwitch API on the server using the ServerApplicationContext. Coupled with the ease of using Web API you can provide custom service interfaces to your LightSwitch server logic to provide smart, custom, RESTful HTTP services to a host of clients.

With this practical example, I hope I not only showed you how to retrieve user permissions but also gave you a glimpse of what is possible. Stay tuned to the LightSwitch Team blog for more examples like dashboards and reporting scenarios.

@Rom -- the JS simply makes a call to the server. The server code is compiled and cannot be seen. But keep in mind that whoever makes the call must already be authenticated -- that's already happened once you get there. Also notice that I'm not returning any usernames/passwords in the JSON so it's not identifiable.

@Robert - In this release in order to manage user's and roles, first add a desktop client to your solution (right-click on the solution and "Add client". Then when you deploy your app, you will get the administration screens. If you want to see the admin screens while debugging, grant for debug the SecurityAdministration permission on the Access Control tab of the project properties.

I added this code to my project, its works perfectly on my development machine in both debug and release modes, but when I deploy the app to Azure the client query fails to return the permissions. Have you any idea what I might have missed?

I currently have the code to get the permissions in my startup switchboard page. The code to then check permissions is in the clients pop up screen - this enables/disables the add button which works fine.

I then tried putting the check permissions code in the startup page so I can switch the visibility of groups of buttons depending on the logged on user's permissions. This fails however fails due to myapp.permissions not being defined.

On checking I can see that the server side code hasn't run yet when the JS is checking permissions. Is there a way around this please.