- 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 the Application Based on User Roles
A ClickOnce deployed application is no different than any other .NET application when it comes to role-based security. If you want to control what users can do with your application based on the roles they are associated with, you can use .NET principal permission demands. .NET principals can be based on a user's logged-in identity, or they can be based on custom authentication credentials and roles.
You can use role-based security in .NET to make security demands through either attributes applied to methods, classes, or assemblies, or you can make them imperatively with code. The following code shows an example of using principal-based security demands to ensure that only users in an appropriate role get to execute certain sections of code.
[PrincipalPermission(SecurityAction.Demand, Role = @"Managers")]
private void DoSomethingPrivileged()
{
// Do manager stuff
if (Thread.CurrentPrincipal.IsInRole(@"BUILTIN\Administrators"))
{
// Do admin stuff
}
}
In the preceding code, only users who are associated with the Managers role will be allowed to execute the DoSomethingPrivileged method. The inline check using the CurrentPrincipal property on the thread lets you check whether the user is in a particular role and execute conditional code based on that.5