Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Managing .NET Code Access Security (CAS) Policy : Page 5

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.


advertisement
Additional Utilities
Selecting the Runtime Security Policy node in the Microsoft .NET Framework 1.1 Configuration tool shows several utilities in the work area, shown in Figure 14. The Increase Assembly Trust and Adjust Zone Security wizards are quick ways to grant or restrict permissions to code. They are not fine grained solutions demonstrated in my previous walkthrough. Using one of these wizards means that you could end up granting an assembly more permissions than it needs. Additionally, using one of these wizards changes default security policy. You could accidentally modify security policy on all machines. In contrast, setting a specific code group that targets an assembly is simple and leaves the existing policy settings in place. You'll have to consider these tradeoffs among others as you establish security policy.
 
Figure 14: Runtime security policy utilities.
Other utilities in run time security policy include Evaluate Assembly, Create Deployment Package, and Reset All Policy Levels. I have mixed feelings about the value of Evaluate Assembly. Since .NET determines final security at run time, the information you retrieve from this tool about security requirements doesn't provide the full story. The only way to view the evidence of an assembly is to run code that examines evidence during run time.

The Create Deployment Package utility lets you set policy within an enterprise when you have full control of all machines. However, deploying your solution to customers, where you don't have full control, requires consideration because you can't just overwrite their policy with what you think it should be. Instead, you should consider using an MSI that runs code you've developed to merge and uninstall your policy. Before you establish CAS policy, you should have some type of configuration management procedure in place that specifies what the policy should be. A good configuration management process will help you recover if you ever run the Reset All Policy Levels utility, wiping out all the work you've done.

Code Access Security (CAS) allows you to secure your system based on the identity of code. Evidence defines the origin of code, and permissions specify what code is allowed to do. The process that maps evidence to permissions is specified by CAS policy, which uses code groups and policy levels to resolve the set of permissions granted to an assembly. The Microsoft .NET Framework 1.1 Configuration tool is a graphical user interface for working with CAS policy. It contains wizards for creating code groups and permissions. Additionally, it offers utilities that help you implement CAS on your system. Overall, CAS provides you with a powerful set of capabilities for maintaining security in the managed environment.



Joe Mayo is an author, independent consultant, and trainer specializing in .NET technologies. He operates the C# Station Web site (www.csharp-station.com) and is a Microsoft MVP. Joe is the author of "C# Unleashed" (Sams) and "C#Builder Kick Start" (Sams).
Comment and Contribute

 

 

 

 

 


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

 

 

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