SharePoint 2010 Business Connectivity Services Security Best Practices – Permissions And Authorization

The various permissions associated with Microsoft Business Connectivity services are all associated in various ways. This can be with an individual account, a group account, or a claim with several different levels of permission in place for a given object within a metadata store. It is crucial that the settings for permission for any object in Microsoft Business Connectivity Services is done correctly. This will allow it to create solutions for securing access to external data. The strategy for permissions needs to be carefully evaluated during the planning stages. It is a good idea to provide specific permissions to each user or each group. The goal is to offer credentials that provide only the privileges that are necessary in order for them to perform necessary tasks. The overall security strategy you have is important. Don’t overlook the value of it for your external systems too. The way in which you will set permissions up can vary by business and implementation purpose. Take various security models and features into consideration before you decide how you will proceed with it.

There is a metadata store that is inside of each instance in the Business Data Connectivity Service. This includes the external content types, methods, external systems, and all the models which have been defined for the purpose of that store. There is a hierarchy among those objects used to determine which of them can be used to gain permission to other objects. Each of the objects will gain permission from parent objects. The idea is to set up the permissions so that all of the settings for children of a given item can be replaced by those of the parent object. There are four permission levels that may be set for the metadata store: Execute, Set permissions, Edit, and Selectable in clients.
There are many objects that have to be taken into consideration to determine what type of permissions to set. As you go through them you will be able to determine what is best for you to use.

External Content Type – The external content type offers a collection of metadata that can be reused. This metadata defines one set of data from others that are used with external systems. All of the connectivity information that is related to certain groups of data is maintained here. There aren’t any edit permissions with the external content type. However, the setting can be used for permissions linking to child objects in the metadata catalog. The user is able to execute permissions and create external lists in client permissions. The user is able to set permissions with external content type.

External System – The external system is a metadata type of support for sources of data. They can be modeled like a database, web service, or .NET for connecting purposes. The user is able to edit the external system so that the permissions are accessible though SharePoint Designer. There aren’t any execute permissions or selectable permissions with the external system. However, the settings can be used to gain permissions to child objects that are part of the metadata catalog. The user is able to set permissions on the external system.

Metadata Store – This is the collection of .XML files that are stored in the Business Data Connectivity Service. Each of them contain definitions for external systems, external content types, and all the models. The user is able to create new external systems if they wish. There isn’t an execute permissions with the Metadata Store. However, it can be used to create permissions in child objects according to what is listed in the metadata catalog. There aren’t any selectable clients in permissions either. Yet the settings can be used to create permissions along with child objects in the metadata catalog as well. The user has the ability to set permissions on any object within the Metadata Store.

Method – The method is the type of operation relating to an external content type. The user is able to edit the method being used. There aren’t any execute permissions or selectable in clients permissions available in method. However, the user is able to set permissions for it.

Method Instance – The method instance is a description for how to use a given method with a given set of default values is in place. The user can edit the method instance. They can also use execute permissions. However, there aren’t any selectable in client’s permissions. The user is able to set permissions on the method instance.

Model – The model is a .XML file that has sets of descriptions for one or more of the external content types. It also contains descriptions for their external systems that relate to it. All of the information that is specific to a given environment including authentication is stored here. The user can edit the model file if they wish to do so. There aren’t any execute permissions or selectable permissions for models. However, the user can change and set the permissions in the models as they see fit to do so.

There are more than just general capabilities when it comes to setting the permissions that were described earlier. There are special permissions to consider with the Business Data Connectivity Service as well:

  • Application Pool Accounts This pertains to front end servers and they must have the same permissions as Farm Administrators to the Business Data Connectivity Service. This is necessary in order to create deployment that will be based on Microsoft Business Connectivity Services.
  • Farm Administration They will have full permission to access the Business Data Connectivity Service. This is so they are able to properly maintain, fix, and update the service as needed. The Farm Administration doesn’t have the ability to execute permissions though on any object in the Metadata Store.
  • SharePoint Designer Users They will be given a series of permissions for the entire Metadata Store. This includes the ability to edit, execute, and select clients. They aren’t given permission though to set permissions. It is possible to limit the permissions of the SharePoint Designer to a subset for the Metadata Store as well.
  • Windows PowerShell The users are Farm Administrators and they have the ability to operate various commands with the Business Data Connectivity Service.

There are plenty of common tasks that take place in the Business Data Connectivity Service. Here are the permissions that are necessary in order to be able to perform them:

  • Adding a new object in the Metadata Store The user has to edit permissions on the parent metadata object.
  • Adding external content type to a model the user has to edit permissions on the model.
  • Deleting an object from the Metadata Store The user has to edit permissions on that object. This includes the parent and all of the child objects.
  • Deploying a package This is generated by the application pool account used by the front end server. This has to have full permissions to the Business Data Connectivity Service for this task to be completed.
  • Exporting models The user has to edit permissions on the model and for the external systems that are within that model.
  • Importing models The user has to edit permissions for the Metadata Store. The user that imported it will typically be the one given permissions for such roles to take place.
  • Setting permissions on the Metadata Store To initially get the Business Data Connectivity Services permissions have to be set. They are empty after first and the Farm Administration has to go to the Metadata Store and install those initial permissions.

XmlFormView Control And Forms Services

The XmlFormView control plays the central role in rendering the display to a user in an HTML compatible format. When not using the Forms Service XmlFormControl within a WebPart, it becomes exceptionally difficult to develop a custom solution to render out the InfoPath form. It could be theorized that one could load the InfoPath XML document by calling a StreamReader on the XML contents, go through all the XML contents, use LoadXml to load the streamed contents, apply the relevant style by looping through the nodes, and other methods. However it is much easier to do it with the Forms Services native XmlFormView control by simply calling it out, and a lot of the methods that would have to be custom written otherwise are handled by the control.

The XmlFormView control can also be consumed from within a SharePoint WebPart or a SharePoint WebPart Page because the required page references are already stored within the SharePoint 12 hive.

WebPartPage XmlFormView Control Registration and Placement

There are very few requirements to get the control to display on a WebPart page within SharePoint. Namely, making the references to the appropriate assemblies to consume the control and then declaratively calling the XmlFormView control. Therefore, it is possible to open a WebPart page using SharePoint Designer. Call the XmlFormView control on the page, and set the relevant properties to point to the .XSN file location.


<%@ Register Tagprefix=”InfoPath”
Namespace=”Microsoft.Office.InfoPath.Server.Controls” Assembly=”Microsoft.Office.InfoPath.Server, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>


For some environments, a more modular approach is required, and therefore the XmlFormView should be packaged within a SharePoint WebPart to display relevant InfoPath forms. In order to consume the XmlFormView control within a WebPart, the task is pretty straightforward. Make a reference to the Microsoft.Office.InfoPath.Server assembly and declare a field to hold the control.


private XmlFormView proSP2007Form;


Override CreateControlControls()

Like the rendering of all child controls that exist in .NET, we simply have to override the CreateChildControls() method and then call out the XmlFormView Control.


protected override void CreateChildControls()



proSP2007Form = new XmlFormView();

proSP2007Form.XsnLocation = “proSharePoint2007XSNlocation”;




Then following in the RenderWebPart method, override the RenderWebPart method and output the XmlFormView control.


protected override void RenderWebPart(HtmlTextWriter output)






By filling in the XSNLocation property, the XSN you want displayed is rendered through a WebPart. If you want to extend the WebPart, use a WebPart property to make the XSN location property adjustable by users through the WebPart ToolPane.


Building A Simple SharePoint 2007 / WSS v3 WebPart

First Steps In Creating A Simple SharePoint 2007 (MOSS) / WSSv3 WebPart

There are several differences that exist between the ways that WebParts were written in the SharePoint 2003 framework as opposed to the SharePoint 2007 (MOSS) framework that dramatically increases the functionality that is available to the developer. As written about in previous articles, there has been a dramatic shift in how WebParts are structured within the 2003 framework and the 2007 framework.

What Has Changed?

The way that WebParts are programmed in WSS 3.0 has changed drastically, however the benefits of programming WebPart instead of standalone .NET application remains the same. One of the most important things that is covered with the introduction of WSS 3.0 is the legacy style of creating WebParts (although both inherit from the WebPart class, in 3.0 this class is located in System.Web.UI.WebControls.WebParts namespace, and in WSS 2.0 this base class was located in the Microsoft.SharePoint.Pages namespace) is still maintained, and although the environment may have changed, programmatic efforts will not have been wasted. Since the new WebPart framework is based on the ASP.NET 2.0 framework, in order to maintain functionality and rendering capability there has been changes to the Microsoft.SharePoint.dll, referenced heavily when creating new WebPart projects.

WebPartManager Control

The most important concept to grasp in relation to developing ASP.NET 2.0 WebParts is the WebPartManager control (Note: this is in relation to ASP.NET 2.0 WebPart development, we will touch on the WSS 3.0 control responsibility for rendering shortly). This control serves a very important purpose in relation to the new technology of WebParts, mostly tailored around the serialization and de-serialization of WebPart related data since this data is transported from the database.

Starting to Create the WebPart

The first step in creating a new WebPart is to open the Visual Studio 2005 client (you can also use notepad if you wish to compile with the CSC command). You are then going to create a new project. When the project selection screen comes up, choose a class library, and then in language selection box choose either C# .NET or Visual Basic .NET, depending on yours or your client preferences. Name your project Hello World. When building SharePoint 2007 WebParts, and since it is common for the WebParts to exist within the GAC, you must modify your assemblyinfo.cs (or.vb) file in order to build the project with a signed assembly. This can also be done through the Visual Studio 2005 command prompt using the sn.exe command.

Open the class file that is located in your Visual Studio project. In this file, you will see at the top using statements (for the remainder of this article the examples will be provided in C#, but for brevity it will be imports statements or VB.NET). Through the use of adding references to this portion, will gain access to different options to inherit portions of code that would otherwise require several re-writes of code that is already placed into the framework.

Adding the Necessary References

The first reference that you will see in the default class library is the System. We will have to add other using statements in order to properly build other WebParts. Firstly, ensure the following references are made:

  • System
  • System.Web.UI
  • System.Web.UI.WebControls.WebParts

This should look like the following when added to your C# class file, located at the top before any other code (again, this should read imports …. if you are using VB.NET):


using System.Web;

using System.Web.UI;



Following, as explained before, we will have to change some of the inheritance so that our WebPart class will inherit out of the System.Web.UI.WebControls.WebParts namespace. Our class is called HelloWebPart, therefore we will have to create this inheritance by placing the following syntax.

Exposing SharePoint Specific Assets

For exposing certain SharePoint specific information and objects, there will have to be other references added to the project file. For the context of a Hello World WebPart, we are just facing text out of a WebPart, which doesn’t require access to the SharePoint object model, since in aggregate this is considered just an ASP.NET 2.0 WebPart. If for example, we wanted to query data out of a SharePoint list, we would have to add a reference to the Microsoft.SharePoint.dll, and then write some custom code to query the actual list. In order to setup access to the lists, you would have to first get the content of the current site as demonstrated below:


SPWeb HelloWorldTestSite = SPContext.Current.Web;


Then establish a reference to the list that we wish to query:


SPList Hellos = HelloWorldTestSite.Lists[HelloList];


In order to get all the items, there would have to be an enumeration set that would query through all of the objects of the list following:


foreach (SPlistitem Hellos in HelloList);

//Place your query logic here


Afterwards, you could massage the data as necessary and configure your display programmatically depending on your project requirements.

The Actual Hello World Code

Afterwards, to get our WebPart to render out some simple text, we will have to create some code that will parse out our message. It should look like the following when complete:


using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls.WebParts;

namespace helloworld {

public class helloworld : WebPart {

protected override void RenderContents(HtmlTextWriter writer) {

writer.Write (Hello World):





By placing the above code, you will get a simple SharePoint WebPart that when deployed will place the text Hello World within the WebPart.

Once built, you will get a simple assembly (or binary depending on semantics used within your organization), that can deployed to a SharePoint server pending some further modifications.

Deploying the WebPart for Use With Your Portal

There are two main locations where you can place a WebPart so that you can expose it to your users within your portal. The two places where a WebPart can be placed are:

  • GAC (Global Assembly Cache)
  • /bin directory of your SharePoint instance

For some organizations, placing a WebPart assembly within the GAC is not acceptable, since assemblies placed in this directory are run with full trust, and therefore not subject to several aspects of CAS (Code Access Security), so for the sake of this article we will deploy the WebPart to the local bin of the SharePoint site.

By default, your site collection will place relevant files for your SharePoint instance into your inetpub/wwwroot directory, where there is also a bin folder located, therefore the deployment path is inetput/wwwroot/bin for our SharePoint WebPart.

We can modify the path for where our WebPart is going to be deployed by going to the properties of the project (right click on the top level solution file from within Visual Studio.NET 2005 and select properties from the fly-out), where there are a great many other options outside of the deployment path, including setting the strong key that we are going to use. Under the build shuttle, under the output path, you can change the path to your SharePoint bin directory by placing the path C:\inetput\wwwroot\bin, where the final build will be placed.

Following, and similar to the architecture of SharePoint 2003, all WebPart have to have a safe control entry within the portal web.config in order to run correctly. This is an excellent feature since if there is a problematic WebPart that exist within your environment it is simple to switch it off in order to take it out of the entire environment until a remedy is implemented making it safe again for you to run.

Getting the WebPart to Appear On The Page

The steps in order to get the WebPart on your arbitrary SharePoint page are pretty straightforward. Navigate to the site actions menu on your site and go to the WebPart gallery. Select New which will allow you to add the newly deployed WebPart by selecting the checkbox next to your newly deployed project. Lastly, select the Populate Gallery option in order to deploy the WebPart for use within the portal.

Following, when you edit a page, you will be able to select the WebPart from the WebPart selection dialog through a variety of mechanisms including SharePoint designer and the GUI.