Mark Levison

Musings on No Touch Deployment, .NET development and photography

<July 2008>
SuMoTuWeThFrSa
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789


Navigation

Other

Blogroll

Subscriptions

Post Categories



Click Once Permission Elevation - a good start, but...

Whidbey's new Click Once (No Touch Deployment version 2), offers a new feature called "permissions elevation" .Net Security Blog:

"Permission elevation allows a ClickOnce application to specify that it would like to run with a specified set of permissions, and it can be granted these permissions without the need to have the user modify their policy." 

If the user grants the permissions the application is run.  If the user denies the permissions the application won't be run at all.

This is a huge improvement over the existing No Touch Deployment (NTD) in VS 2003, but it is only a start.  To explain the problem, I will describe our application and Permissions Elevation's limitations.

We've developed a NTD app for use over both intranets and the internet.  Our app checks to see what permissions it has and then quietly degrades the functionality (as recommended in Matthew Lyons chapter "Writing a Semi-Trusted Application") if they're not available.  The thinking is the application should always run and adapt if the permissions are not available.

Permissions elevation all or nothing approach is the opposite of the way we developed the application.  We would like some permissions (like unmanaged code for excel export), but can live without most of them.

To make use of the permissions elevation feature we will need to create two (or more) links on the web page to launch the app.  The first link will be: "Launch the app with many permissions and all features", the second "Launch the app with the default permissions and fewer features".  While the framework has avoided any issues with the complexity of optional permissions, the burden is being pushed down to the NTD developers and our end-users.

Improvements I'm asking for:
Whidbey: If the user denies the permission request, then the application can still be run with its original permission set.
After Whidbey: Give the users an explanation of the features and the permissions they are tied to.  Perhaps allowing the user to add permissions once the program is installed and running.  Consider this scenario: John launches the NTD app from the internet with the standard low trust permission set.  After doing some work he wishes to export the data excel.  He chooses File -> Export -> Excel and up pops a dialog saying, "the application has asked for unmanaged code permission to complete this action". 

If you agree with me then vote for FDBK14571 on ladybug (aka labs.msdn.microsoft.com/productfeedback)

posted on Saturday, August 28, 2004 8:43 PM by mlevison





Powered by Dot Net Junkies, by Telligent Systems