Permission set levels (topmost has the fewest)
Nothing - no permission including execution
Execution - permitted to execute but without resources
Internet - execute, windows, file dialogs and limited isolated storage
LocalIntranet - DNS services, environment variable access, unlimited use of isolated storage
Everything - all permissions except skipping type-safety verification
FullTrust - all permissions and access to resources

There are 4 different levels of security policy:
application doman (ASP.NET)
enterprise (Network administrator)
machine (Machine administrator)
user (Single user under OS)

Code groups and security policy

Membership conditions  

Condition  Corresponding evidence  
Application directory  The address of the assembly, particularly the assembly's installation directory  
Cryptographic hash  The hash of the assembly code, which indicates it hasn't been tampered with  
Software publisher  The Microsoft Authenticode signature and public key, which identifies the software publisher  
Strong name  The strong name identifies the publisher and proves that the assembly hasn't changed since publication  
URL  The particular web address where the assembly was published  
Web page  This condition applies to applications that are presented on web pages, and not as individual assemblies  
Web site  The site on which the assembly was published  
Zone  The security zone � local computer, local network, or Internet � from which the assembly originates  

Role based security
All users in a business or application can be assigned roles, which are logical groupings related to the application or system. Role based security can be combined with Code base security to provide a more effective security model. User identity holds login information and principal contains role membership information.

WindowsIdentity object (Windows OS authentication)
GenericIdentity object (Not using Windows OS authentication
IIdentity has three properties: Name, Is Authenticated, Authentication
WindowsPrincipal and GenericPrincipal classes and an IPrincipal interface

Call stack walks
Whenever a call is made requiring permission, the system automatically checks access rights to the resource. Call-stack walks are inefficient. By asserting a permission you can forestall a call stack walk. You can write your own code to manually enforce permissions, which is called issueing a security demand. All standard predefined permission classes are stored in system.security.permissions namespace.
EnvironmentPermission class - controls access to system and user variables
SecurityPermission class - set of security permissions in code
UIPermission class - clipboard and user interface permissions

Permission objects
FileDialogPermission - open, opensave, save (file and folder access)
FileIOPermission - read, write, pathdiscovery, append
IsolatedStorageIOPermission - usage of private virual file system: none or unrestricted
IsolatedStoragePermission - usage of generate isolated file storage: none or unrestricted
ReflectionPermission - access to metadata through system.security.permissions.reflectionpermission
RegistryPermission - controls access to registry variables

Imperative security

You can imperatively issue security demands and asserts methods. Demand triggers a call stack walk. Circumvent the call stack walk by using Assert. The .NET Framework completes these demands automatically and there is no need to make a demand for a call stack walk, however, the demand can be completed by an assembly. Special permission is required to use assert but not demand method.

Permission object methods:
Deny
PermitOnly
RevertPermitOnly, RevertAssert, RevertDeny
IsSubsetOf, Union, Intersect

Declarative security

Declarative security uses attributes to modify security settings for assemblies, classes and methods.

VB.NET Example:
< FileIOPermission(SecurityAction.Demand, Read:="C:\Perms") > Public sub LookAtFile(ByVal filename as string)

Imperative security is visible at run time, declarative security demands are checked upon loading.

Permview tool

The Permview tool allows user of an assembly to scan for declarative security demands. User can anticipate the kinds of security permission their code will need when the assembly is being used. All permission objects have corresponding permission attributes. Imperative security actions are hidden to users of an assembly. Declarative security is stored within the manifest, imperative security is not a part of an assembly.

VB.NET Example:
< FileIOPermission(SecurityAction.Demand, Read:="C:\Perms") > Public sub LookAtFile(byval filename as string)

Securityaction value:
demand
assert
deny
permitonly
linkdemand
inheritancedemand
requestminimum
requestoptional
requestrefuse

Declarative security  
Can be implemented only at assembly, class, or method level  
Parameterized during build time  
Exceptions thrown only in callers  
Visible to assembly users  
Inherently simpler than imperative security  
Best suited to using permission requests with link demands  
Uses attributes to modify security for assemblies, classes and methods

Imperative security  
Can be implemented at assembly, class, or method level, or within a method  
Parameterized during runtime  
Exceptions thrown and handled in methods  
Hidden to assembly users  
Inherently more complex than declarative security  
Doesn't support using permission requests with link demands  

Using permissions in VB.NET

Imports System.Security.Permissions
	Module Perms
		Sub main()
			LookAtFile("C:\Perms\myFile.txt")
		End Sub
		'Callers must have access to C:\Perms
		< FileIOPermissionAttribute(SecurityAction.Demand, _
		Read:="C:\Perms" > > _
		Public Sub LookAtFile(ByVal filename As String)
		Dim unmanagedPerm As SecurityPermission
		Dim fileIOPerm As FileIOPermission
		Try
		'Define the File access permission object
		fileIOPerm = New FileIOPermission( _
		FileIOPermissionAccess.Read, filename)
		'Make sure callers have the correct permission
		fileIOPerm.Demand()
		'Allow access to unmanaged code
		unmanagedPerm = New SecurityPermission _
		(SecurityPermissionFlag.UnmanagedCode)
		unmanagedPerm.Assert()
		' call unmanaged code
		' code not included***
		Console.WriteLine("File read")
		unmanagedPerm.RevertAssert()
	Catch ex As Security.SecurityException
		Console.WriteLine("Security exception: ")
		 Console.WriteLine("Security message  : " & ex.Message)
		Console.WriteLine("Security type     : " & _
		ex.PermissionType.ToString)
		End Try
		End Sub
	End Module

Link Demands

Link demand is a special form of declarative security check that determines whether permission exists to a caller. A security exception may be thrown at an undetermined time and in such a case try/catch is not reliable unless used with another method, each caller passes the security check.
< FileIOPermission(SecurityAction.LinkDemand, read:="C:\Perms") >
Public function the LinkedMethod() as string
' Access a resource
End function

Inheritance demands

Inheritance demands can be used at the class or method levels.
Class inheritance example:

< FileIOPermission(SecurityAction.InheritanceDemand, read:="C:\Perms") >
Public Class newclass
   ' Class implementation
End Class

Method inheritance demand example:

< FileIOPermission(SecurityAction.InheritanceDemand, read:="C:\Perm") >
Public Overridable Function newMethod() as integer
   ' Access a resource
End Function

Identity permissions

Identity permissions are granted using evidence which does include strong name, download url, authenticode signature, originating zone. Used in a declarative syntax form to demand caller belongs to a particular zone or that the caller is published by a particular publisher.

< ZoneIdentityPermission(SecurityAction.Demand, Zone:=SecurityZone.MyComputer) > 
Public Function newMethod() as Integer
   ' Access a resource
End Function

Suppose you need your assembly to be called only from assemblies installed on your local computer - demand the callers zone is SecurityZone.MyComputer.

< ZoneIdentityPermission(SecurityAction.Demand, Zone:=SecurityZone.MyComputer >
Public Function newMethod() as integer
   ' Access a resource
End Function

Additional identity permission classes included in the .NET Framework:
* PublisherIdentityPermission - authenticode signature of assembly
* StrongNameIdentityPermission - assembly strong name
* SiteIdentityPermission - website originated
* URLIdentityPermission - originating url
* ZoneIdentityPermission (shown in above example) - my computer, internet, intranet

Ideally an assembly should not load unless the minimum set of permissions is available to it. You could code around not having local storage access and instead use isolated storage or memory.
There are three types of permission requests:
* RequestMinimum - specifies minimum set of permissions required to execute
* RequestOptional - request additional permissions not included in minimum set
* RequestRefused - specifies permissions that should be denied to your code

VB.NET Identity Permission example:

' Request minimum
< Assembly: SecurityPermission(SecurityAction.RequestMinimum, Flags:=SecurityPermissionFlag.UnmanagedCode) > 
' Request optional
< Assembly: SecurityPermission(SecurityAction.RequestOptional, Flags:=SecurityPermissionFlag.ControlPrincipal) > 
' Request refused
< Assembly: SecurityPermission(SecurityAction.RequestRefuse, Flags:=SecurityPermissionFlag.ControlPolicy) >
< Assembly: SecurityPermission(SecurityAction.RequestRefuse, Flags:=SecurityPermissionFlag.ControlThread) >

Custom Permissions

.NET Framework predefined permissions should suit your purposes. There are situations where custom permissions are appropriate to protect resources:
* When no permission class protects a resource
* Inadequately controlled access right to a resource that is protected
* Permission protects the resource but not in a way that meets your needs

Custom permissions should be defined in a way they do not overlap which could cause unnecessary processing overhead. To implement a custom code access permission:
* Implementing IPermission and IUnrestrictedPermission, and/or possibly ISerializable
* Handling XML encoding and decoding
* Optionally adding support for declarative security by implementing an Attribute class

Configuring security policy using the MFC tool

.NET Framework comes with the MFC (Microsoft Framework Configuration) and Caspool (Code Access Security Policy tool) utilities. Both are used to configure security policy on a machine.

MFC
Common reasons you might need to change security policy:
* External assemblies deployed locally will have local access rights
* Legitimate assemblies may not be able to run correctly if denied access rights to some resources
* Default security gives full access to local assemblies, security is not enforced during development
* A security policy you create in a zone may be quite restrictive; either redeploy the assembly or change security for specific assemblies rather than changing zone policy

Development must be tested using expected zone security policies. Restricting access rights might be required in such a case.

The Trust Assembly Wizard, allows you to increase level of trust applied to a particular assembly or publisher.
The Adjust Security Wizard, allows you to change security settings for an entire zone.
These wizards are found in administrative tools - Microsoft .NET Framework Wizards in the control panel.
There is a sliding bar to change level of trust for zones; my computer, local intranet, internet, trusted sites and untrusted sites. By default untrusted sites are denied even the ability to execute.

Example adjustment of security policy:
* Open .NET Framework configuration tool
* Open runtime security policy
* Click enterprise, machine or user
* Click code groups to display current set of groups
* Add a child code group, starts the create code group wizard
* Select a condition type: All code, Application Directory, Hash, Publisher, Site, Strong Name, URL, Zone - using strong name public key from the assembly's manifest by using the ildasm tool or you can click the import button and browse to the assembly
*Enter the assembly name, version is optional
* Assign a permission set; fulltrust, skipverification, execution, nothing, localintranet, internet, everything
* Click the finish button
* Repeat for enterprise, machine or user level (if needed)

Example change of zone security policy:
* Select adjust zone security
* Select current computer or current user
* Highlight the zone and slide the bar up for additional trust level
* A summary appears, click finish

Example of deploying a custom security policy on local machine:
* Select create deployment package
* Select machine option
* Choose a folder and file name for the new package
* Click finish

Example to view permission sets:
* Click enterprise, machine or user
* Click the permission set you want to review
* Click view permissions
* A list of all permissions appears at the level selected
Note: It may be difficult to keep track of permissions each assembly requires, the Permview command allows you to view the permissions an assembly requires; here is a sample permview commandline C:\system\microsoft .net\1.1\permview /decl codefile.exe (/decl indicates declarative security demands)

Caspool - Code Access Security Policy tool
This tool is installed with the .NET Framework SDK. If the user has administrator rights Caspool policies are applied to machine level, if the user does not have administrator rights Caspool policies are applied to the user level. Administrator defaults can be changed to -en -m or -u to change the default. Caspool has built in warnings, backups and a reset.
Sample caspool commands:
-lg or -listgroups
-lp or -listpset
-all, -machine, -user or -enterprise
-lf or -listfulltrust
-u -recover (replace existing user level security policy with previous policy backup)
-m -lp (list permission sets associated with machine policy level)
-en -af test.exe (adds enterprise fulltrust to assembly text.exe)
-en -remfulltrust test.exe (remove full trust abbreviation is -rf)
-m -addpset newPset newPermissions (adds new permission set called newPermissions to machine policy, defined within newPset.xml file)
-user -addgroup 1. - zone Intranet Execution (adds a child group to the root of the user policy code group, member of intranet zone receiving execution permission set)
-resolvegroup test.exe
-resolveperm test.exe
-user -chggroup 1.1 -site www.test.com (edits membership condition of second child group so test.com is a member
-m -recover (recover changes from last backup of machine policy)

.NET role based security

All principal and identity objects must implement IPrincipal IIdentity objects.
IIdentity public properties include AuthenticationType (passport, windows, kerberos), Name (current user), IsAuthenticated (boolean). IIdentity classes include WindowsIdentity (IsAnonymous, IsGuest, IsSystem) and GenericIdentity. Two methods of WindowsIdentity are GetCurrent and GetAnonymous.
VB.NET example:
Dim myID as WindowsIdentity
myID = WindowsIdentity.GetCurrent()
Dim myPrin as new WindowsPrincipal(myID)

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)

To call SetPrincipalPolicy you'll need permission from system.security.permissions.security.
dim myPrin2 as WindowsPrincipal = CType(System.Threading.Thread.CurrentPrincipal, WindowsPrincipal)

Create a GenericIdentity object passing a string representing the user's name
Dim myId as new GenericIdentity("Toby")
Dim myPrin as New GenericPrincipal(myId, new String() {"Administrator", "Debugger"))

After principal and identity objects are established, you can check user identity information and role membership using String.Compare, WindowsPrinipal.IsInRole or GenericPrincipal.IsInRole and PrincipalPermission.Demand.

'Compare two strings, ignoring their case
Console.WriteLine(String.Compare(myId.Name(), myId2.Name(), True))

Dim myId as WindowsIdentity = WindowsIdentity.GetCurrent()
Dim myPrin as new WindowsPrincipal(myId)
Console.Writeline(myPrin.IsInRole(WindowsBuiltInRole.Administrator))
Values include Administrator, Guest, PowerUser, User

Check membership of multiple roles