.NET 3.5 & Visual Studio 2008 in 2007! :-)
Visual Studio 2005/2008, "Delay signing" message text fuss.

.NET Security: CAS vis-à-vis Migrating 1.1 code base to .NET 2.0: StrongNameIdentityPermission

Be very careful with the .NET Security Identity permissions that you may be using in your code, when planning to migrate the code base to .NET 2.0+, especially the StrongNameIdentityPermission (SNIP)

When you have SNIP .NET CAS identity permission being used on any of your highly privileged code, and require that all calling code (including FullTrust code) calling on this SNIP’d method(s) to have strong name signed using the same key as is in the called code, you may be feeling warm and cosy thinking that you may have completely secured all external access to your code.

Your assumption stands true in a .NET 1.1 CAS Security context, but not in the .NET 2.0 CAS context.

What is happening is that in .NET 1.1, unlike most other CAS permission classes which implements IUnrestrictedPermission interface, the CAS Identity permissions cannot have the Unrestricted permission state value set up on them.

Since the Identity permission do not implement this interface, nor otherwise allow the Unrestricted state value to be set on them, even the FullTrust assemblies that are granted all unrestricted permissions, cannot successfully pass the SNI permission demanded by your code (in .NET 1.x).

With that in place, a reasonable assumption that a .NET CAS security based app design will make about its fully secure code access, holds true – i.e. just because a calling assembly is a FullTrust assembly, it cannot pass/skip the SNIP permission that your code demands (when it was not signed with the public key that the called code is signed with), and will fail to access your secure code if it is not signed with the same public key as yours.

But CAVEAT! That assumption won’t hold good in .NET 2.0 security.

In .NET 2.0 CAS, the Identity permission classes ALLOW code to set the Unrestricted state value – i.e. PermissionState.Unrestricted.

The impact of this change in .NET 2.0 security is that if you migrate your .NET 1.1 code to 2.0 or later, your highly privileged code won’t be protected anymore by the StrongNameIdentityPermission, from any abuses by any FullTrust assemblies.

In .NET 2.0 CAS, FullTrust code can call your SNIP secured code, without having to meet the demands of the IP – i.e. any FullTrust code that is not signed with the public key that your secure code requires, can still call on your secured code.

Result: Your .NET 1.1. CAS SNIP protected code is not protected anymore when run in .NET 2.0 CAS context.

Review you CAS protected code thoroughly! If you see something like this:

public class BusinessObjectClass


[StrongNameIdentityPermissionAttribute(SecurityAction.Demand [or LinkDemand], PublicKey="<the key bytes">")]

public void YourCASProtectedMethod()

{ /* Your privileged code... */ ... }


... then its time to take action (if migrating to .NET 2.0).

Oops!! Hell breaks loose? Well…. Yes!

So, when migrating the code base to .NET 2.0, ensure to change your CAS dependant design on securing your code by either of these:

  • Just don’t expect StrongNameIdentityPermission (SNIP) to secure your privileged code, and attempt alternative CAS or other security strategy, OR
  • Use the application configuration setup route, and direct the runtime to use the legacy CAS .NET security policy behavior (1.x) for Identity permissions.

You could do this by using the legacyV1CASPolicy element, and set its enabled value to true.

I have some more neat strategies in mind, to sort out this .NET security issue vis-à-vis migrating code to .NET 2.0. I will blog more about those later. Watch this space.

In one of my .NET consulting projects, I am advising my customer on this exact .NET security issue :-)… so thought you all will also benefit from this bit of advice!

Next, I will blog about some precautions you will need to take when working with CAS in .NET 2.0 (vis-a-vis your .NET 1.1 code base migrated to .NET 2.0) when invoking delegates of methods (in another assembly) that are protected by CAS security demand.

The key thing here to be careful about is that there are additional checks made by CAS 2.0+ on the delegate invoker's .NET security related assembly identity bits, which you will need to be aware of so that you can have your .NET 1.1 code updated for .NET 2.0, to take into account and provide for these additional checks.

Although your current code for .NET 1.1 will work fine as-is after migrating, if the above specific aspect of CAS 2.0's additional security checks is not taken care of, then the runtime will throw security exceptions. So CAVEAT!

- Sundar



Thanks for this nice blog. It was instantly useful to my work here, and i have to thank you because i had never realised that this much of thinking is needed with CAS development.

I wish MS supplied such nice notes ;-) like you are doing.

Thanks again.

Just a request: Would you be OK if i kept in touch with you via email?
We are currntly looking for some top notch .NET security planning consultants, and i have already forwarded your blog site url and web site address contacts to my company management. I am sorry i did this without asking your consent first.

Thanks for your blog entry... it was very very helpful. I have to tell you that i have now developed some special interest in laerning .NET CAS, after reading your blog.


Absolutely a gem post, and its a live saver!

I am currently migrating from 1.1 to 3.5 (a big jump) and I never knew about this issue and i think i would have never known about it, since we would not have tested the migrated code in .NET 2.0 or 3.0 specifically for full trusted code accessing the secure code and ending up calling it without even passing the SN identity permission demand.

This helped me a lot. Thanks a million. Your advise on this will be another tip in my architect's belt to remember.

Your advise is worth $1000s on security planning on migration of code from 1.1 to 2.0+. Keep more coming. I am in the middle of migrating, code, and so all your .NET security tips will be very handy!

Like others are saying in other posts, please keep blogging more!

The comments to this entry are closed.