kamagra how much to take

Considerations for Security Relating To SharePoint Configuration Elements

There are several elements that exist in SharePoint that heavily relate to configuration, and if properly configured, your SharePoint, and ASP.NET 2.0 applications alike will be securely configured and perimeter facing ready. Some of the elements that are going to be detailed are not specific to SharePoint, but instead are related to ASP.NET 2.0, however understanding the overall concept will help you secure your collaboration environment.

There are several layers of configuration that can affect SharePoint security, some more impacting than others. Like the programmatic model that exists in the .NET framework that heavily builds upon the OOP concept of inheritance, the same type of architecture exists within the configuration elements that provide elements to SharePoint and ASP.NET 2.0 applications.

Machine.Config File

The first element, the root, and which provides that base for the inheritance is the machine.config file, which obviously provides the configuration elements for the entire machine, whether it is your SharePoint server or IIS server running ASP.NET 2.0 applications. The machine.config is a powerful, yet dangerous place to make changes to configuration elements because they will effect the overall operational architecture of the machine. Before making changes to the machine.config it is best practice to make several backups during the process, and analyze and study the changes you plan to make before implementation.

Root Web.Config File

The second element is the major, or root, web.config file. It is easy to confuse this configuration file with the web.config file that SharePoint developers are accustomed with that exists in the root directory of their SharePoint virtual server. This is not the case with this file. Rather, the root web.config holds several important settings that will effect the overall operation of the .NET framework. One of the bigger shifts that exists between 1.1 and 2.0 is that a lot of the configuration elements that were previously defined in the machine.config file are instead declared in the root web.config file.

Virtual Server Web.Config File

The third element is the web.config that exists for the application, or at the root of the virtual server. You can easily view this file by opening up the IIS MMC snapin, browsing through the tree of sites that exists, and selecting explore. In the right pane there should exist a web.config file for your application. Most SharePoint developers are familiar with it because of the neccsity to add safe control entries for web parts to run correctly (assuming that you are newing up a webpart in 2007 as opposed to deploying a .cab file with stsadm). It is the same place that various other site specific elements should be defined such as HTTP modules, and other things that are not going to be shared across all virtual servers. This, and the last element are typically the most modified configuration elements in a SharePoint environment since the others cause such major changes in an environment.

Nested Web.Config Files

The last element is if you have more than one config file defined within your SharePoint application. It is not necessary that there only be one config file defined, rather, you can have more than one config file that is specific to an application if the application exists in a subdirectory of other applications. This is very common when you create several virtual directories that exist under a website though the IIS MMC snap-in, and farily common with SharePoint developers when you are simply integrating an application into SharePoint (as opposed to writing it directly against the framework, such as using a page viewer webpart, and taking into account your managed path settings!).

Using Programmatic Methods To Read Configuration Settings

The configuration settings can be read and wrote programmatically as well through .NET compliant, along with other languages if you so choose to for whatever purpose, although this is fairly uncommon in SharePoint since most of the editing that you will do happens through direct edits and then doing an iisreset /noforce to have those changes take effect. Recycling the application pool will not have the desired effect as a best practice, when making changes to any backend XML files it is best to bounce IIS. For some of the configuration settings, there are already classes that are provided that derive out of various base classes, such as those for the role provider that are already defined, however you can still if you choose still read and write various configuration information from such assets as the web.config file specific to your application. For these types of operations, you are going to look at the configuration manager class. To use this class, you are going to have to make the appropriate namespace references, namely system.web.configuration and system.configuration.

The power in the configuationmanager class is the specification of sections. For sections that exist in your web.config file, you can use the configurationmanager class in order to query and/or write to those sections with information as you choose, very helpful if you are trying to build application functionality where you parse various information to the user screen, such as what functionality may be enabled that is sponsored primarley through configuration changes that appear in configuration files. The method that you can use to get various sections of configuration information is the GetSection method (this is a static method), that will get a various section that may exist in your configuration files. The usage of this method is rather simplisitic, and looks like:

  1. ConfigurationManager.GetSection(your_sharepoint_or_whatever_section);

This can be very powerful when building reporting tools that will provide detailed configuration metrics in regards to your deployment of configuration elements. When using this class, it is important to realize that however you are leveraging the method that you need read access to the data whether you are impersonating or binding direct account parameters. This is pretty constant when reading configuration information, a majority of IIS permission levels are already taken care of since the WPG account typically already has read access in a SharePoint environment to the web.config file and the .NET framework web.config file, and optionally has read access to the web.config file if you plan on modifying that as well.

WebConfigurationManager

The ConfigurationManager class is useful when you are looking at a specific application, but what if you want to transverse multiple applications and look for arbitrary sections of information. This is when you have to use a different class, namely the WebConfigurationManager class, which is very powerful when scaling to various applications that may exist on a machine. The WebConfigurationManager looks similar to syntax structure to ConfigurationManager, as seen below:

  1. WebConfigurationManager.GetSection(your_sharepoint_or_whatever_section, ~blah.config);

Whereas with ConfigurationManager it was scoped to an application, we instead introduce a secondary parameter to a configuration file that can be determined however you want, this is a very powerful concept.

Locking Assets In Configuration Files From Redefinition In Child Configurations

There are two assets that can be locked within configuration settings, attributes and elements, which makes sense for an XML defined file as the configuration files that interact with SharePoint and ASP.NET 2.0 application as a whole. Within your configuration file, you can apply the lock attributes to lock down specific configuration assets, namely attributes and elements, to adhere to a corporate standard, or limit visibility and possibly inheritance through other child configuration files.

Locking Attributes in Configuration Files

The first asset that you can lock down is attributes in a configuration file, this will in effect lock redefinition of attributes in configuration files. The two attributes that you can use are the lockAttribute and lockAllAttributesExcept attributes, each which have a very different purpose. lockAttributes is a powerful attribute that restricts redefinition of attributes in children configuration files, and lockAllAttributesExcept is a typically much more efficient way of locking attributes if you have more locks in your file than freedom, as you can guess with lockAttributes you are locking specific attributes and with lockAllAttributesExcept you are defining which attributes should not be locked. It really depends on how many locks you wish to iterate through within your configuration file. The first of these is easily define in a configuration file, and looks like the below for locking individual assets in a configuration file:

  1. < blah configurationAttribute=someAttribute  lockAttributes=configurationAttribute >

This would in essence lock the settings in an arbitrary configuration file so that configurationAttribute could not be redefined in child configuration files. You could separate multiple attributes by using a semicolon delimited list of all the attributes that you wish to lock.

For the second locking possibility, lockAllAttributesExcept, it would look like the below:

  1. < blah configurationAttribute=someAttribute  lockAllAttributesExcept=configurationAttribute >

If you implemented this, the only attribute that could be redefined is the configurationAttribute, so in subsequent child configuration forms you could only define:

 

  1. < blah configurationAttribute=myAttribute >

This is the only attribute afterwards that you could define in child configuration forms, so one can see the possibility of bulk locking configuration attributes. Similar to using a semicolon delimited format to lock multiple singular attributes with the lockAttribute attribute, the same can be achieved with the lockAllAttributesExcept attribute.

Locking Elements in Configuration Files

The second asset that you can lock down is elements within a configuration file, this is a very powerful mechanism. Similar to lockAttributes, lockElements allows you to lock elements in a configuration file as opposed to attributes. Similar to how lockAttribute also had a sister function for bulk locking, so is the case with lockElements which also defined the lockAllElementsExcept, which allows you to lock all elements beside the ones you specific declare, very helpful for massive configuration and much faster than locking each element you wish to define.

In the SharePoint configuration files as well as the machine.config file that is one your SharePoint server, there are nested elements that exist, lockAttributes and lockAllElementsExcept allow you to lock parent configuration elements to prevent redefinition of those elements in child configuration files.

In your configuration file, there are several sections that you can use this on, for example if you have a section:

  1. < MySharePointSection >
  2.  
  3. < mySharePointElement >
  4.  
  5.                                 < mySharePointNestedElement 1 / >
  6.  
  7. < mySharePointNestedElement 2 / >
  8.  
  9. < mySharePointElement >
  10.  
  11. < MySharePointSection / >

Now you could lock redefinition of these elements by putting a:

  1. < MySharePointSection lockElements=mySharePointElement >

Trying to redefine mySharePointElement in children configuration files will after the locking implementation will then fail because the element has been locked in a parent configuration file.

Similar to the locking attributes we saw that could be modified in bulk using the lock all except rhetoric, the same type of functionality exists with elements. It looks like the below:

  1. < MySharePointSection >
  2.  
  3. < mySharePointElement lockAllElementsExcept=mySharePointNestedLement 1 >
  4.  
  5.                                 < mySharePointNestedElement 1 / >
  6.  
  7. < mySharePointNestedElement 2 / >
  8.  
  9. < mySharePointElement >
  10.  
  11. < MySharePointSection / >

This would allow you to essence lock that eliminate from redefinition a very powerful concept, particularly if you have security elements that are define in your parent configuration files that you never want redefined in other subsequent sections.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>