sk any typical .NET developer about Code Access Security (CAS) and you've got the chance of hearing "Huh?" as the response. Most developers haven't run into CAS at alllet alone in a way that would cause them to develop a deep understanding of it.
Ask your typical SharePoint developer about CAS and they're likely to begin to shudder uncontrollably. Why is that? Well, SharePoint developers have been dealing with CAS since the day that SharePoint was released. Unlike ASP.NET, which makes the assumption of full trusteffectively neutralizing any impact that CAS will have on a standard .NET applicationSharePoint starts with a minimal trust, which means most code will need to have a CAS policy applied to it in order to work.
Until.NET 2.0 switches the default from full trust, not much is likely to change on that front. But there has been one change in .NET that will encourage some Web developers to dig into CAS: new support for web parts. As Sharepoint developers know, Web parts are bits of code that can be plugged into application frameworks and be used to construct a visual interface. It is not unlike the way that user controls can be added to a web page except that web parts are designed to be moved and controlled at run time, not design time.
In this article I'll explore what every web developer needs to know about CAS policies, and how they fit with both SharePoint and ASP.NET 2.0
Before I drop into the details of what CAS is, you need to understand its place in the security world, including what it is not and why it's necessary. We are all familiar with Windows' basic security structure, which allows or denies operation based on the user who is logged in. We're also aware that all too often we're running as administrators on our local machines because eventually every user runs into something they need to do that requires administrative privileges.
The problem, which has been demonstrated again and again by wave after wave of viruses and worms, is that any code that is run, intentionally or accidentally, by the user has all of their permissions. In the case of a user who is an administrator, that means it can do anything. This is a bad situation, not only because this effectively puts users in charge of what code to run on a case-by-case basis, opening the door for mistakes, but also because it's intrusive to the user. Being prompted for access time and again as software is loading eventually becomes tiresome.
To complicate the problem, consider the case of a hosting company that is trying to make sure that several applications run on the same server without interfering with one another. There may be permissions that one application requires that they wouldn't want to give users directly. Such is the case with SharePoint, which will only run on a machine where the user is qualified as an Administrator (or Power User). That's more permissions than you would generally want to give to a hosting customer.
Enter CAS. CAS doesn't approach security from the perspective of the logged in user and their role on the system. It augments role-based security; it doesn't replace it. It approaches security from the perspective of a trust level for the code being run. In this way, users who log in to the system as administrators can still be restricted from performing certain actions that, under role-based security, would always be in their purview. The level of trust for a particular program, then, provides another way to secure a systemwith a lesser permission set than the users have themselves.
Suddenly, you have a way to allow the user to directly delete files but to prevent an applicationsomething that they downloaded from the Internet, perhapsfrom doing any deletions. Web hosting companies have a way to allow SharePoint to access the entire system while limiting the customer's access to only areas they should have access to.