- ClickOnce Security Overview
- Internet Explorer Security Settings Affecting ClickOnce
- Configuring ClickOnce Security Permissions
- Understanding and Managing Publisher Certificates
- Signing Application Updates
- User Prompting
- Trusted Applications' User Security Policies
- Trusted Publishers' Permission Elevation
- Adding Restricted Code Sections
- Securing the Application Based on User Roles
- Securing Access to ClickOnce Application Files on the Server
- Where Are We?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Securing Access to ClickOnce Application Files on the Server
ClickOnce does not include any built-in provisions for restricting access to the application files on the deployment server. If you are using ClickOnce to deploy an application to the local Intranet, and the Windows identity of the logged-in user can propagate to the deployment server via Windows networking (i.e., no firewalls between the client and the deployment server), then you can use Windows Access Control Lists (ACLs) to restrict access at the file or folder level on the deployment server to specific users or groups. If you do this and a user attempts to launch an application to which she has not been granted file access rights, one of two things will happen.
If the user has been denied access to the .application file (the deployment manifest) and she tries to launch a ClickOnce application through a link or URL, she will see an HTTP 401 error (access denied) in the browser. If the user is allowed to get to the deployment manifest, but is denied access to the application manifest or any of the application files, she will get a launch error dialog like the one shown in Figure 6.31. The details under this dialog will specify that there was an HTTP 401 access denied error.
)
Figure 6.31 Authentication Error Launch Dialog
If you have an application that you are deploying over the open Internet or a network where you cannot rely on the logged-in identity of the user to get passed to the deployment server, then there is no practical way to secure access to the server files. When you deploy an application with ClickOnce, it is a set of individual file requests from the client machine to the deployment server. There are actually two for the deployment manifest (due to a level of indirection supported by the runtime where one deployment manifest can point to another), one for the application manifest, and then one for each application file. These file requests are not correlated in any way.
You can prevent users from being able to do a normal ClickOnce application launch by using an online-only application that you have to launch from a Web application that requires a login to access, but you can only restrict access to the .application file in that case. The request for the .application file will be made by the browser, but the subsequent file requests are made by the ClickOnce runtime and will not contain any cookies or headers from the previous file requests.6 Each file request is completely isolated from the others.