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!

Permission schema

General schema for permissions:

<Permission class=”[class name, assemblyName]” version=”[version number such as “1”]”>
   […permission specific XML…]
</Permission>

Explanation: [class name] indicates the name of the class as URI. For instance for all standard permissions the class name will be System.Security.Permissions.nameofstandardpermission. The assemblyName consists of a name, optional assembly version and the assembly’s compact strong name originator. Since every standard permission is included in the mscorlib assembly all stadard permissions have the following schema:

<Permission class=”System.Security.Permissions.NameOfStandardPermission, mscorlib, [ver=”XXX.XX.XXXX.XX”], SN=03689116d3a4ae33” version=”1”>
      …Permission XML…
</Permission>

The assembly version for mscorlib can be omitted, this way the latest version of the permission class is being used.

Each permission has permission specific xml elements (see sections on various permissions). The version attribute value is used to indicate the version of the xml configuration syntax with respect to NGWS frameworks and runtime releases. This will facilitate backwards compatibility.

This document will now lay out the schema for the standard permissions as well as for custom permissions. For details on the permissions please see the Security Permissions specification.

Schema for the EnvironmentPermission

This permission controls the access to environment variables.

Schema:

<Permission class=”System.Security.Permissions.EnvironmentPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
   (<Read> [list of environment variables] </Read> |
   <Write> [list of environment variables] </Write>)v<Unrestricted>
</Permission>

Explanation: The read tag is optional and is followed by a list of case insensitive names of environment variable. Variables are separated by semicolon. The write tag is optional and also followed by a variable list demarcated by semicolons. Instead of the read/write tags the <unrestricted/> flag may be set also.

Example: Permission to read Files and Path variable, permission to write ACCESS variable

<Permission class=”System.Security.Permissions.EnvironmentPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
   <Read>”PATH”;FILES</Read>
   <Write>ACCESS;”My;var”</Write>
</Permission>

Schema for FileDialogPermission

This schema controls the extent to which a file dialog may be used.

Schema:

<Permission class=”System.Security.Permissions.FileDialogPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      <Unrestricted/> 
</Permission>

FileIOPermission schema

This permission determines the extent file input/output is allowed.

Schema:

<Permission class=”System.Security.Permissions.FileIOPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      (
      <Read>[list of files or folders]<Read/> | 
      <Write>[list of files or folders] <Write/> |
      <Append/>[list of files or folders] </Append>  
      ) v <Unrestricted/> 
</Permission>

Explanation: lists of files and folders are semicolon separated path names, or path+ file names. The read/write/append tags must not appear in that order, a subset of these tags may be used (such as only the read tag). The unrestricted tag cannot appear in combination with the read/write/append tags.

Example: permission to read from c:\temp and to read the file D:\MyFiles\document.doc to which also append rights have been given.

<Permission class=”System.Security.Permissions.FileIOPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      <Read>C:\Temp;D:\MyFiles\document.doc<Read/>  
      <Append/>D:\MyFiles\document.doc</Append> 
</Permission>

unrestricted file access

<Permission class=”System.Security.Permissions.FileIOPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      <Unrestricted/>
</Permission>

IsolatedStorageFilePermission schema

This permission determines how the isolated store may be used.

Schema:

<Permission class=”System.Security.Permissions.IsolatedStorageFilePermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
(
<UserQuota>[number of bytes]</UserQuota> |
<MachineQuota>[number of bytes]</MachineQuota> |
<Expiry>[no of days after which permission expires]</Expiry>|
(<DomainUser/>v<AssemblyUser/>v<AssemblyMachine/>v<AdministerUser/>v<AdministerMachine/>v<None/>v<Unrestricted/>) |
<Permanent/>
) v <Unrestricted/> 
</Permission>

Explanation: This permission sets specific amounts of trust for the isolated storage

Example:

<Permission class=”System.Security.Permissions.IsostorePermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      <DomainUser/>
      <UserQuota>157000</UserQuota>
      <Expiry>40</Expiry>
      <Permanent>True</Permanent>
</Permission>

SocketPermission schema

This permission controls access to Sockets

Schema:

<Permission class=”System.Security.Permissions.SocketPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      <Transport>(TCPvUDP)</Transport>
      <Hostname>[ip address or dns name]</Hostname>
      <Port>[port number or wildcard denoting all ports]</Port>
</Permission>

ReflectionPermission schema

This permission permits the ability to read the name and type information of non-public members of types, as well as to find subclasses and superclasses and what module and assembly the class is in.

Schema:

<Permission class=”System.Security.Permissions.ReflectionPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      (<TypeInformation/>|<MemberAccess/>|<ReflectionEmit/>)
      v<Unrestricted>
</Permission>

Example:

<Permission class="System.Security.Permissions.ReflectionPermission, mscorlib, SN=03689116d3a4ae33” version="1">
      <TypeInformation/>
      <MemberAccess/>
      <ReflectionEmit/>
</Permission>

RegistryPermission Schema

This permission is used to separately set read, write and append rights to specific keys/values. As with the FileIOPermission read/Create or write tags cannot appear along with the unrestricted tag.

Schema:

<Permission class=”System.Security.Permissions.RegistryPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      (
      <Read>[list of keys and values]</Read> | 
      <Create>[list of keys and values]</Create> |
      <Write>[list of keys and values]</Write>
      ) v <Unrestricted/> 
      
</Permission>

Example:

<Permission class=”System.Security.Permissions.RegistryPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      <Read> some keys,values separated by semicolon</Read> 
      <Append></Append>
      <Write></Write>
      
</Permission>

SecurityPermission Schema

This permission is used to set a variety of simple permission flags used by the security system. The execution flag must be granted for an assembly to be to run. The assertion flag is used to grant an assembly the ability to assert any permission it has been granted (again, for more details see the permissions specification). The unmanaged code flag is used to indicate that an assembly can call unmanaged code. The skip verification flag allows code to run without passing verification. And finally the thread control flag allows code to do thread operations.

Schema:

<Permission class=”System.Security.Permissions.SecurityPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      (
      <Execution/> | 
      <Assertion/> |
      <UnmanagedCode/> |
      <SkipVerification/> |
      <ControlThread/>|
      <ControlEvidence/>|
      <ControlPolicy/>|
      <ControlDomainPolicy/>|
      <ControlPrincipal/>|
      <SerializationFormatter/> 
      )v<Unrestricted/>
</Permission>

Example: The permission below allows code to execute, bypass verification and to call unmanaged code.

<Permission class=”System.Security.Permissions.SecurityPermission, mscorlib, SN=03689116d3a4ae33” , version=”1”>
      <Execution/> 
      <UnmanagedCode/> 
      <SkipVerification/> 
</Permission>

UIPermission Schema

This permission defines access to various aspects of the Windows UI: use of display windows, use of clipboards (and events – not implemented yet). For use of windows as well as the clipboard various gradations of trust can be set by a variety of exclusive flags (viz. if Nowindows tag appears Allwindows tag cannot appear also in the permission).

Schema:

<Permission class=”System.Security.Permissions.SecurityPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      (
      <AllWindows/> v
      <SafeTopLevelWindows/> v
      <SafeSubWindows/> v
      <NoWindows/> 
      ) |
      (
      <AllClipboard/> v
      <OwnClipboard/> v
      <NoClipboard/> v
      )v<Unrestricted/>
</Permission>

Example: Code gets granted the permission to use safe top level windows and any clipboard access.

<Permission class=”System.Security.Permissions.SecurityPermission, mscorlib, SN=03689116d3a4ae33” version=”1”>
      <SafeTopLevelWindows/> 
      <AllClipboard/> 
      <VersionTag>XMLNotationV1</VersionTag>
</Permission>

Custom Permission Schemas

Custom permissions can be defined to control access to resources not covered by the standard permission (or to allow for finer granularity in the control of protected resources addressed by standard permissions). Developers need to define custom permission objects that must support various APIs (such as de/encoding into XML – for more details see Permission specification).

Schema:

<Permission class=”[link to custom permission class], [name, [ver=XXXX.XX.XXXX.XX], SN=[compact strong name originator of custom permission assembly]  “ version=”[version number such as 1]” >
      […Custom permission specific XML – freely definable by custom permission developer… ]
</Permission>

Explanation: class=”..” must contain the name and namespace of the class that implements the custom permission, furthermore the assembly name needs to be given (as containing a name, strong name originator and possibly the assembly version). The only other requirement on a custom permission schema is that it is valid XML, that the custom permission class must be indicated as shown.

Note that custom permission assembly needs to be properly registered with and loaded into the Fusion cache.

Example:

<Permission class=”MyApp.Permissions.MyDBPermission, mylib, SN=44555jhw8whhs” version=”1”>
      <DB Name=”PayRecords” Access=”Read”/>
</Permission>