Securing UI elements

Topics: CAB & Smart Client Software Factory
May 20, 2006 at 4:56 AM
originally posted by: julio_e_pozo

Does CAB security support restriction at the view / control level?
So far I have only seen security at the module level by configuing ProfileCatalog.xml or implementing my own IModuleEnumerator.


May 24, 2006 at 1:13 PM
originally posted by: Lethal_Byte

I don't think it does. Maybe this is something they consider when they start introducing more of the UI Process (assuming they do, and I hope they do!).

For now, I'm pretty sure you'll have to roll your own implementation for this. A good start would be the Security Application block that ships with Enterprise Library 2.0. This touches on the idea of permissions, etc.
Jun 17, 2006 at 12:04 AM
originally posted by: johanandries

The hands-on labs show an application of the object builder in which certain UI elements are only visible of the user is in a certain role. Probably you can use that as a starting point?
Jun 21, 2006 at 2:49 PM
originally posted by: matiaswoloski


We implemented role-based UI behavior in the Reference Implementation 2. The last drop might show that.
The ActionCatalogService is a new service that we implemented for that purpose.

Basically this is a service that will allow you to execute a piece of code (that we call an action) based on conditions. So it's a more generic solution than simple role-based UI.
However, to fulfill the role-based ui requirement we implemented an EntLibAuthorizationProvider condition.
So you can do things like this:

public void ShowOfficerView( object sender, object target ) {
MyView view = WorkItem.Items.AddNew<MyView>();
WorkItem.Workspaces"MyWorkspace".Show( view );

And then you call this code using
ActionCatalog.Execute( "ShowOfficerView" );

When this action is executed it will go through a series of conditions (pipe & filters pattern). If all conditions return true then it will execute that code.

Right now we implemented only one which is the EntLibAuthorizationProviderActionCondition.
In the App.config we have rules like these:

<add expression="NOT R:Greeter" name="ServiceCustomerAction" />
<add expression="R:Greeter" name="ShowAddVisitorToQueueCommand" />
<add expression="R:Greeter OR R:Officer OR R:BranchManager" name="ShowCustomerQueueManagementView" />
<add expression="R:Greeter OR R:Officer OR R:BranchManager" name="ShowFindCustomerCommand" />
<add expression="NOT R:Greeter" name="ShowOfficerQueueView" />
<add expression="NOT R:Greeter" name="ShowPurchaseCDCommand" />
<add expression="NOT R:Greeter" name="ShowPurchaseCDView" />

You could use the ActionCatalog service from within your Views and implement methods like:

public void ApplyUiSecurityForOfficer( object sender, object target ) {
txtCustomer.Visible = true;
txtPurchaseId.ReadOnly = true;
listBoxItems.Visibule = false;

public void ApplyUiSecurityForAnonymous( object sender, object target ) {
txtCustomer.Visible = false;
txtPurchaseId.ReadOnly = false;
listBoxItems.Visibule = true;

In the initialization of the view you would call:
ActionCatalog.Execute( "ApplyUiSecurityForView1" );
ActionCatalog.Execute( "ApplyUiSecurityForView2" );

Then you might have the rules in EntLib that says action ApplyUiSecurityForView1 could be executed by RoleA and RoleB.
ApplyUiSecurityForView2 could be executed by RoleC and User1.

The final release will have more documentation about this.

Matias Woloski
patterns & practices Smart Client Software Factory Team