Newer versions of .Net and .Net core has have removed and/or changed “Code Access Security” (CAS) since this question was asked.
I encounter code access security quite often in the "real world", often when I least expect it. And in a way, SilverLight would be an excellent real-world application of it, were it not that SilverLight chose not to employ CAS at all in the end.
The places where you see it in action is where a secured environment is needed: ASP.NET itself of course, but ASP.NET hosting providers use a modified security model to prevent intrusion in their precious systems. I know for a fact that Webhost4Life uses this (no information on their site about it, but I've worked with them, it's there, really). Looking further, other ASP.NET hosting providers do the same, but they are not very clear about it either: thread on godaddy.com not wanting to change the CAS (and no clarity what's supported and what not) or this related discussion on 1&1. Some cloud hosting sites (rackspacecloud) took it a bit further and "worked with Microsoft for a modified full trust level" whatever that may be.
In short: if you find an ASP.NET host, most likely they've used CAS to prevent you from doing things they don't want you to do. They can even use it make difference between "basic" (many restrictions) hosting and "enterprise" (few restrictions) hosting which gives a whole other meaning to CAS.
So much for a few real-world situations that I encountered myself. A recent project I did had something similar: allow the user to upload a library, and test it for performance ("who makes the best algorithm"). Needless to say, we needed CAS heavily there. Other examples or interesting resources:
For any situation where you are simply in full control yourself, you build your own app and code (or have it built) and are in complete control of your system, I don't think you'll need CAS too often. It's more something you'd use the minute you get to run code from lesser trusted sources (which is basically everything that's not in your full control).
Default CAS settings limit the capabilities of code run from a network share or other non-local sources. This makes sense but the stringent restrictions make it hard to have a central repository for distributed application. .NET 2.0 introduced ClickOnce, which was supposed to elevate the security (discussion here).
ClickOnce itself uses CAS, to prevent the installer from calling into system functions. As such, I believe it is arguably the best well known application that relies on CAS.
Point being: you need to understand CAS to be able to create something that can run directly from a share, or you ignore it all and use ClickOnce.
In 2005, Microsoft summoned a survey to find out why CAS was so unpopular, hoping to improve it to make it better applicable. Unfortunately, I couldn't find the actual survey results, other then this post somewhat detailing why CAS is underused.
That post, however, does point at an intriguing niche: CAS applied to another world: Unix / Linux. They don't call it CAS, instead it's BitFrost. How's that for a real-world application: the "One Laptop Per Child" project, which relies on BitFrost as a replacement for the traditional Unix security model.
Update: section on CAS in Unix/Linux as BitFrost and section on survey.
Update: added CAS vs ClickOnce section
Update: added list of resources using CAS (and apologies for all these updates in a row!)
Technically, it's very useful as it allows a very fine grained permission specification. This is both good for you (as theoretically it makes exploiting security vulnerabilities a lot harder - even if an attacker gains full control over your app, he is still locked in the CAS Sandbox) and for your customer (as they can see exactly what your application can do and run their own security audit).
In practical use, it's mostly meaningless. I think it's too complex, too little supported by the available dev tools and most users don't care anyway.
There are exceptions of course (Governments and customers who really know .net/CAS) and I would love to say that CAS is absolutely useful and mandatory, but the reality speaks a clear language.
I was the development lead on a project to get JITC certification (US Department of Defense) for a .NET based solution, and the CAS settings were scrutinized very closely during the certification testing.
Like most of the other certification requirements, the code could only use the privileges it needed to work and no more.
If you are planning to get security certifications CAS can definitely be important.
Note to reader: see the two comments below; it sounds like I'm accidentally inflating the definition of CAS to (incorrectly) include RBS. I'll leave the answer here for reference, but note the distinction.
There are two havles to CAS; the thing you'll see most about in that exam is all the nuances for code calling other code, which may be useful for partial trust, but most of the time it is simply a pain - and worse: if your code has full trust (which most / too-much does) none of it actually executes (it is skipped entirely).
The useful part of CAS RBS is principal permission, which is used; of course, your UI should verify access to features, but you can put (in your low-down logic):
[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")]
static void DeleteOrder(int id) { ... }
This will be enforced even in full trust; you can define your own principal (tied to the user) by implementing IPrincipal
(look at IsInRole()
). And since principals are supported in most environments (winforms, webforms, mvc, wcf, etc) this can make for a very flexible way to double-check security at the business layer without having to reference the specific security model. Note that the above check would work in any environment.
You can also perhaps use this to drive your UI. I did have a usenet post that enabled / disabled winforms controls based on the principal (using runtime properties to specify the role per control, a bit like ToolTip
etc) - I can't find it at the minute, though (edit: maybe this one).
We used CAS for our Applications was not really to hard, since we'd only tried to stop unauthuorized code execution. Problems came up once using our software from local network share, but a cas-policy cleaned the problem out.
Since update of .NET3.5 our problems were not existent anymore, since code on local area network is now handled like local code.
One thing you should know is that Code Access Security is pretty much broken as a method for tamper-proofing. See:
CAS Tamper-Proofing is Broken: Consequences for Software Licensing
...
Code Access Security can no longer be relied upon to prevent the use of tampered assemblies in shipped products. This means that if your application is dependent upon Code Access Security to perform licensing checks, it is trivial for an attacker to replace your licensing assembly with another, thereby gaining free access to your application.
...