How Do I...Control access to my shared component?

Every assembly loaded by the common language runtime is assigned evidence that describes its identity. This evidence can be the path or URL from which the assembly was loaded or it can be a digital signature given to the code by its publisher. To control access to your code, you can simply demand that your caller have a specific identity. For example, to limit access to a shared component to only code from the same publisher, the publisher would sign all their code and then place a demand for that signature within their shared component.

The identity permissions found under the namespace System.Security.Permissions are used for this purpose. Identity permissions are provided for the following types of assembly identity: strong name, Authenticode publisher certificate, URL of origin, site of origin, and Internet Explorer security zone. All identity permissions support three types of identity demands as described below:

• Demand: All callers on the call stack are required to have the specified identity. This check is performed at runtime.
• LinkDemand: Only the code's immediate caller is required to have the specified identity. The caller must be trusted to not allow misuse of the called code by its own callers. This check is performed during loading.
• InheritanceDemand: Requires the specified identity of any code that attempts to inherit from or override a method on the protected code. This check is performed during loading.

Below is an example of making a link demand on a method for a strong name identity. The public key has been abbreviated for readability.

Public Shared Sub _
  <StrongNameIdentityPermission(SecurityAction.LinkDemand, PublicKey := "002400000...")> _
  ProtectedMethod()
    'do something
End Sub

The additional properties Name and Version can also be provided. By specifying Name, Version, and PublicKey, an exact version of an assembly can be reliably demanded. Specifying only Name and PublicKey will allow the demand to succeed if the assembly name and signature match regardless of the assembly version. Specifying only the PublicKey, as in the code example above, causes the security system to look for only the required signature and is useful when you desire to limit access to a group of code signed by the same key.

Attaching a strong name signature to your code involves two steps: creating the strong name key and compiling your assembly with that key. The first is accomplished by using the SN utility that is provided with the .NET Framework SDK. Below is the command-line syntax for creating a key pair and viewing the public key portion (you will need to make an identity demand for code signed with the corresponding private key).

sn -k keypair.dat

sn -p keypair.dat publickey.dat
sn -tp publickey.dat

<Assembly: AssemblyKeyFile("keypair.dat")>

Public Class MyClass
    'something interesting
End Class

It is also possible to delay-sign an assembly. This reserves room for the signature in the assembly manifest but does not actually sign the assembly. Delayed signing is used when the author of the assembly does not have access to the private key that will be used to generate the signature. For more information about delayed signing, see the reference documentation on AssemblyDelaySignAttribute.

VB CodeIdentityDemand [Run Sample] | [View Source]