Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Managing .NET Code Access Security (CAS) Policy

Toward the end of the project cycle is not the time to figure out Code Access Security. Learning how .NET handles evidence, permissions, code groups, etc. now will put you that much further ahead for your next project.

ode Access Security (CAS) is the .NET Common Language Runtime (CLR) mechanism for maintaining security based on the identity of code. Most developers don't have to work with CAS on a daily basis because the .NET Framework libraries take care of much of the work involved in securing code. However, when you do need to work with CAS, having a good understanding of CAS policy management is essential. Waiting until the eleventh hour in the project lifecycle and realizing that you need to configure security policy is painful. For example, if you have a Smart Client application that runs over Internet Explorer, you will need to consider what permissions your application requires and how you are going to configure policy so that your code will run on a client machine. Or, suppose that your application defined a custom permission for a scenario not already covered by the permissions that ship with .NET. Here again you need to understand CAS policy. This article discusses the essential elements of CAS (evidence, permissions, and policy), shows how .NET CAS policy works, and explains reasons for making various policy decisions.

CAS and the Elements of Policy
CAS security is based on the identity of managed code. The need for CAS arose out of the constant execution and threat of malicious code on the Internet. A quick look at what has been done up to now in the way of security can help set perspective on the value of CAS. Previous efforts to stem the tide of malicious code were not enough. There was, and still is, role-based security that maintains security based on the identity of the person that is running the code. Role-based security was, and still is, an important element in system protection. But in this day and age it is not enough.

Certificates and sandboxes for ActiveX controls, applets, and script were the first widespread commercial means to apply security measures to code. Initially these efforts simply prevented code from running until the user gave the code permission. However, these security implementations either gave code all permissions or none, thereby preventing it from running; there wasn't a middle ground that gave users a choice. In the case of ActiveX controls, non-technical users had to choose whether or not to let unknown code run on their system, exposing a dangerous situation for someone to make an uninformed mistake and allow malicious code to execute. All-or-nothing and on-demand security methods have their places but they are not enough. Internet Explorer improved upon some code security by introducing zones that allowed code to receive a certain amount of trust based on where it was launched from. This good idea is now part of the present CAS strategy. However, CAS takes this idea and goes further.

In CAS, code contains evidence that identifies its origin. The evidence could be a zone, publisher, or one of several other types of evidence. CAS policy evaluates the evidence and resolves/assigns permissions that a piece of code is allowed to have. .NET supports many permission types, giving you a fine level of granularity in choosing what code can do. Additionally, you can configure CAS policy on multiple levels, letting you explicitly plan and specify a policy that keeps your system secure and allows only necessary code to run to let you get your work done.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date