Sep 2

Written by: kchristo
Friday, September 2, 2011 

This is my approach to making screen authorization (show/hide) more effective and robust that hard-coding permission names in the “_CanRun” partial methods. The library and sample code is published here. As with my previous post the code is posted to msdn and here I will explain in detail how to use the library and what the sample does.

First let’s prepare. After downloading the sample and before you can run you must create a database I use for storing screen security information. Create a database named LSSecurity and then open and execute the script found in the zip at the path Files\LSSecurity.script.sql. Then you have to go to your ServerGenerated\Web.Config and change the connection string from localhost\clcadlocal to the name of your SQL server. This database is imported by the sample Lightswitch application in a datasource called LightSwitchSecurity. The entities from this datasource are used to implement the class implementing the ISecureScreenService interface in the sample.

Note here that the ideal implementation would be one that would integrate this schema to the ASP.NET security database used by LightSwitch but I didn’t go that far.

Now you are ready to run the application.

Before you do though take a look to the Access Control settings:

You can see Authentication is enabled. Windows Authentication is selected for convenience. The infrastructure can be used in any authentication scenario and the implementation presented in the sample is also compatible with any scenario.

When you first run your application, no security service is defined and you see all options available in the Navigation Pane.

 

In this sample the screens All Screens, All Permissions, My Screen Permissions have the SecureScreenAttribute defined. This means that if you don’t define any permissions for them they are only available to a Security Administrator. When you first run the sample SecurityAdministration permission is granted for debug by the settings. That’s why all screens appear. If you remove the SystemAdministration permission from debug mode permissions

then the resulting startup screen should look like this:

The Manage Customers and Manage Products screens don’t have the SecureScreenAttribute defined. That’s why when no security service is defined they appear.

To prove this do the following:

1. Change the SecureScreens project view to FileView
2. Open SecureScreens\Client\UserCode\Application.cs
   
3. Uncomment the line of code in the partial Application_Initialize method
   
   partial void Application_Initialize() {

     InitializeScreenSecurity();

     // Do not uncomment this line before reading the remarks of the blog post.

     //MonitorScreenOpenedNotification();

   }
4. Run the application again.

You will see exactly the same screen. The reason is that the 2 screens have no SecureScreenAttribute defined and they are not handled by the screen security service yet. Our security infrastructure is empty.
Let’s change that. Add the SystemAdministration permission to the set of permissions granted for debug.

Open the All Screens screen. Right now it should look like this (except for the red arrow)

Now press the Synchronize Screens button. All screens implemented in the application will be listed:

Notice the securable column. Manage Products and Manage Customers should have false in the Securable column. The reason is that by default only screens with the SecureScreenAttribute set are imported as securable screens. But you can change that by using the buttons shown by the red arrow in the left. The reason that this buttons are used instead of using checkbox in the Securable column of the grid is that defining if a screen is Securable or not, should (and it’s implemented as you can see going up and down the lines of the grid) only be allowed for screens that do not have the SecureScreenAttribute set.

Now that you have imported the screens, make Manage Products and Manage Customers securable (pressing the little lock button) remove the Security Administration permission and run your application again.
You should be left with no items in the navigation pane. Correct but not nice. Let’s fix this.

First, let’s import permissions. Close the application, add the SecurityAdministration permission (this is getting boring I know but no other way to test), and run the application.

Open the All Permissions screen. This should also be empty

Press the Synchronize Permissions button. All Permissions defined in the Access Control tab should be listed

Save the permissions. (Note you can make the Microsoft.LightSwitch.Security:SecurityAdministration permission inactive but that will have no effect)

Now open My Screen Permissions.

You should be able to notice that in the list left all secure screens are listed (attribute or user secured). But no permissions defined for any of these. Now select the Manage Customers screen and press the add (plus) button to add a new screen permission. Select the LightSwitchApplication:CustomerManager permission from the combo-box and save.

And now FOR THE LAST TIME change the Access Control settings to grand the CustomerManager permission to debug user:

Run the application. You should be seeing this:

You can experiment now with permissions (if you stand messing with Access Control settings again ) and see what happens.

 

Points to Notice

• In the Base.SL.Security.Implementation  namespace you can see the implementation of 3 classes: BasePermission, BaseScreen and BaseScreenPermission. This classes are very simple container classes used to “proxy” the Entities in the LightSwitchSecurity DataSource (that all of the above screens handle) to the ISecureScreenService implementation found in the same namespace. These classes implement the IPermission, ISecureScreen, ISecureScreenPermission. The reason these classes are used, instead of adding the ISecureScreen interface to LightSwitchSecurity:Screen type for example, is done for convenience, since if we did that then we should add references to the Base.SL.Security assembly to almost all projects, as the entity definitions are running across almost all projects (Client,Common,Server, ServerGenerated etc).
• In the same namespace the GenericSecureScreenService and BaseSecureScreenService are implemented. The first one is a generic implementation of the ISecureScreenService interface whereas the second is an explicit declaration of the generic class for the Base… classes mentioned in the previous bullet.
• In the SecureScreens\Client\UserCode\Application.cs the method LoadScreenPermissions converts all the entities from LightSwitchSecurity DataSource into Base… objects and then using the lists created initializes the BaseSecureScreenService instance, which after that is passed to the extention class that is responsible for providing security for the application screens.
• In All Screens screen in the grid there is a column named Display Name. During screen synchronization this property is set either automatically (the camel-case LightSwitch way) or from the SecureScreenAttribute which can take a display name as a parameter. The actual display name of the screen cannot be retrieved by reflection as only an instance of the screen could provide the display name defined in design time. Look to MyScreenPermissions screen partial class to see the SecureScreenAttribute used with a display name.
• The code executed when the Synchronize Screens and Synchronize Permissions buttons are pressed is optimized for updating the security database with the less possible trouble. In my schema, the ScreenPermission table relations to Screen and Permission tables have cascade delete enabled. One can modify the relations, disabling cascade, and have more control over permission changes and less surprises like screens not appearing while they should or vice versa.
• In this sample the ISecureScreenService is implemented to be initialized in memory by the client application. It’s easy (not very but easy) to implement a WCF (or not) service to communicate with, that will not have to be initialized by the client either.
• Notice the remark in the msdn post for automatically generating a partial class that would include all _CanRun partial methods for all screens. If you don’t include any other code in this partial implementation file (unlike the sample) the file can be regenerated every time news screens requiring security have to be handled.
• In the client application partial class there is a line in the Application_Initialize that is intentionally commented out: MonitorScreenOpenedNotification(). Uncommenting this line you ensure that a screen that is not allowed to open for the current user, even if it appears in the navigation pane (because someone forgot to ament the respective _CanRun partial method), will automatically close when user tries to open it. The implementation is rather brute but effective. One can change this to something more elegant (after closing the screen not allowed), redirecting to an informational security error page. The reason I have this line commented out is because lately I have been reading (I had to deal with it to) complains about composition (which is used in the method) sometimes failing to find an IServiceProxy instance. I also faced this issue and I had to include the blank extension to my project. Looks like some special assemblies must be added for composition to be able to recognize IServiceProxy but I am still trying to find out who are they. Anyway, if you are not facing a similar problem, you can uncomment the commented line and have extra security added to you application.
• After publishing/deploying your application you can handle all the changes made by hand, in the Access Control tab of the project’s property pages, by using roles and assigning permissions to them. Like this.

This way the user defined (yes it’s me ) is granted the Customer Manager and Product Manager permission and you don’t have to (actually you cannot after deploying) play with permissions granted for debug.

 

If you managed to read all the way down here I have to congratulate you and hope it was worth it .