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
 

Code Access Security: When Role-based Security Isn't Enough : Page 3

Role-based security works pretty well in most situations but as Sharepoint developers learned long ago it doesn't work for everything. Now that .NET supports Web parts, even more developers will find they need to get a basic understanding of Microsoft's Code Access Security.


advertisement
Security Classes
The SecurityClasses section is perhaps the most straightforward. It lists a set of <SecurityClass> tags for each of the kinds of available permissions. If you open up one of the CAS policy files from the framework directory, as mentioned above, you'll see that there are several <SecurityClass> tags defined and that their format is very simple. They take only two attributes:
  • Name—the name of the class to load in processing the rest of the file. The class can be a permission, a membership condition, or a helper class as in the case of the NamedPermissionSet class.
  • Description—This is the full name of the assembly that the class is found in. This will include the version number, the culture, and public key token. No path information is typically given to the assembly because they are registered in the GAC.
The best thing to do for security class tags is to use the web_hightrust.config as a starting point and remove any security classes that you do not need. This will cover the NamedPermissionSet helper class, all of the membership conditions, and the out of box permissions.

Named Permission Sets
Named permission sets allow you to collect up the various permissions that the code may need into a single set of permissions. This single set of permissions can then be referenced from the code groups that identify assemblies and grant them permissions. The <NamedPermissionSets> section contains a set of <PermissionSet> tags, each of which defines an individual named permission that the code group can refer to.

The basic format of the <PermissionSet> tag has the following attributes:

  • class—This indicates the class to be instantiated. By default, the class is NamedPermissionSet.
  • version—the version of the policy configuration. This has a value of "1" even in .NET 2.0.
  • Name—The name that will be used to refer to this permission set.
  • Description—The description for the policy set.
  • Unrestricted—An optional attribute that when set to "true" allows for unrestricted access. Typically this is only used with a Full trust permission set.
In each <PermissionSet> tag there may be zero or more <IPermission> tags, which associate the permission with the permission set. The <IPermission> tag has the following attributes:
  • class—This is the class from the <SecurityClasses> group above which bestows the permission. This value should precisely match the name attribute of one of the <SecurityClass> tags in the <SecurityClasses> tag.
  • version—As above, this attribute indicates the version and is always set to "1" even in .NET 2.0.
There are several other attributes that may be added to each of the <IPermission> tags based on the class being referenced. The attributes supported cannot be easily ascertained from the documentation of the classes themselves, however, the additional attributes and the permissions that they relate to can be found in the Patterns and Practices guide "How to: Use Code Access Security in ASP.NET 2.0" available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000017.asp. Refer to Table 4 in the article (linked just above) to find a mapping of individual permission classes and attributes to the trust levels built into ASP.NET 2.0. In doing this the Table enumerates all of the options for the ASP.NET permissions classes.





Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap