Code Access Security (CAS) is a hot topic these days, and for good reasons. CAS is an important thing to have an understanding of if you work in a security conscious company, or if you're striving to understand best practices. If you're new to CAS, there are many articles, but I like to describe it with an analogy that we all can identify with. Think of "User Access Security". It's not a coined phrase like CAS is, but essentially it is a conglomerate of rules and measures that enable a given user or person the ability to do something on their computer/network/domain. CAS is the same thing, except with code. If we say John Doe user doesn't have access to crawl files in a sensitive network share, why would we say that third party DLLs (code) can? CAS says "this code can only do X, and nothing more" – much like "John Doe can only do X, and nothing more". CAS is just as important as user access security.

With SharePoint, the thing we try to avoid doing is giving our web applications "Full" trust. Full trust is essentially a CAS policy that gives unlimited access to all assemblies that run within the context of that web application. The main reason in my opinion this is bad is you expose yourself to third party vendors, whose code can essentially do ANYTHING that the app pool identity has privileges to do (which is a lot). Find a nice web part that a guy built in his basement? You've just empowered that guy in his basement to view/play with a ton of your resources – and even phone home with the details.

However, it's not just third party assemblies I'd be concerned with. If you're a large firm with thousands of employees, you don't necessarily even trust yourself. This makes defining your own custom CAS policies all the more important.

NOW THAT WE KNOW CAS IS IMPORTANT…

So you're set on CAS, but you run into an interesting problem with your SharePoint assemblies. Two main SharePoint development practices REQUIRE the assembly to be in the GAC! [The GAC – global assembly cache – is bad because it runs under Full trust all the time.] The GAC equals an open lock and you should only use it when you must! But how do we not use it?

Workflows and Event Recievers are two things you can't build and run them under your own CAS policy, period. Bummer. Since you can't get around it, I always recommend at least two assemblies for each client I work with. One for GAC dependant activities, and one for everything else. For instance, if your company's name is "Contoso" and you're writing SharePoint code for their intranet, the assemblies/projects I would suggest are at a minimum:

Contoso.Intranet.dll

Contoso.Intranet.Global.dll

The global assembly ONLY has workflow and receiver code in it – and nothing else. This way, the majority of your code can run under your custom CAS policies, and you're ensured a more secured future! Note – I wouldn't even put your workflow business logic in the GAC. The workflow can call out to your business logic that is stored in the non-global assembly. So in reality, your global assemblies should be very thin in numbers of lines of code! Only calls to other assemblies that are more secure!

Phil