NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Syntax for declarative security

Declarative security syntax is based on attribute classes. All permission classes that are to be used declaratively will require definition of separate companion attribute classes. Work in progress with compilers on specific implementation issues: here’s roughly what we expect to end up with. (The limited expressive capability of attribute classes – must be representable as constructor arguments with simple types – makes declaration syntax awkward and requires some post-processing, as detailed below.)

using System.Security.Permissions;

// assert file read for c:\temp
[FileIOPermissionAttribute(SecurityAction.Assert, Read=”c:\temp”)]
// demand callers have HKCU registry write access
[RegistryPermissionAttribute (SecurityAction.Demand, Write=”HKCU”)]
// demand callers have named permission set “Everything”
[PermissionSetAttribute (SecurityAction.Demand, Name=“Everything”)]
// inherit only if subclass has permissions specified in file “custom.xml”
[PermissionSetAttribute (SecurityAction.InheritanceDemand, File=“custom.xml”)]

Declarations that are fully self-contained (first two examples) are fully representable with this approach, however references to permission set files (fourth example) need to be resolved to the developer machine at compile time. Specific problem is that the permissions in a file for a declaration are representable in attribute classes are just a reference – thus, if unresolved when the code is run on another machine the file may not be present. Thus, the use of attribute classes for declarative security will require a phase in metadata generation to actually get the file and embed those permissions in the declarative metadata so it will be represented without variation on all target machines. References to named permission sets (third example) do not require this extra step as they are limited to the named permission sets that are shipped as part of default policy and therefore present all machines where managed code may run (specifically, they are limited to the immutable permission sets the contents of which can not be altered—see the Code Access Security Administration specification for more detail).