Business Connectivity Services security overview (SharePoint Server 2010)

 

Applies to: SharePoint Server 2010

**Summary:**The security features of Microsoft Business Connectivity Services enable administrators to safely connect to and interact with external data in a SharePoint Server deployment.

This article describes the security architecture of the Microsoft Business Connectivity Services server and client, the supported security environments, the authentication modes available to connect external content types to external systems, the authorization options available on stored objects, and the general techniques for configuring Microsoft Business Connectivity Services security.

In this article:

• About this article

• Business Connectivity Services security architecture

• Business Connectivity Services authentication overview

• Business Connectivity Service permissions overview

• Securing Business Connectivity Services

About this article

Microsoft Business Connectivity Services include security features for authenticating users to access external systems and for configuring permissions on data from external systems. Microsoft Business Connectivity Services are highly flexible and can accommodate a range of security methods from within supported Microsoft Office 2010 applications and from the Web browser.

Business Connectivity Services security architecture

This section describes the Microsoft Business Connectivity Services security architecture when authenticating from a Web browser and when authenticating from a supported Office 2010 client application, such as Microsoft Outlook 2010.

Security Note

We recommend that you use Secure Sockets Layer (SSL) on all channels between client computers and front end servers. Also we recommend using Secure Sockets Layer or Internet Protocol Security (IPSec) between servers running Microsoft SharePoint Server 2010 and external systems. An exception is that you cannot use SSL when transmitting messages to external systems using the SOAP 1.1 protocol or when connecting to a SQL server database. However, in those cases you can use IPSec to protect the data exchange.

Accessing external data from a Web browser

When a user accesses external data from a Web browser, three systems are involved: the logged on user’s client computer, the Web server farm, and the external system.

1. From Web browsers, users typically interact with external data in external lists or by using Web Parts.

2. The BDC Server Runtime on front-end servers uses data from the Business Data Connectivity service to connect to and execute operations on external systems.

3. The Secure Store Service securely stores credential sets for external systems and associates those credential sets to individual or group identities.

4. The Security Token Service is a Web service that responds to authentication requests by issuing security tokens made up of identity claims that are based on user account information.

5. Microsoft Business Connectivity Services can pass credentials to databases and Web services that are configured to use claims-based authentication. For an overview of the Secure Store Service, see Plan the Secure Store Service (SharePoint Server 2010). For an overview of claims-based authentication, see Plan authentication methods (SharePoint Server 2010).

Accessing external data from an Office client application

When accessing external data from a supported Office client application, two systems are involved: the client computer of the logged on user and the external system. This model is supported when a user interacts with external data by using Outlook 2010, Microsoft SharePoint Workspace, or Microsoft Word 2010.

1. Outlook 2010 users typically use external data in Outlook items such as Contacts or Tasks. SharePoint Workspace 2010 users can take external lists offline and interact with them. Word 2010 users can insert external data into Word documents.

2. The Office Integration Client Runtime acts as a connector between Microsoft Business Connectivity Services running on the client and the supported Office applications.

3. If the external data is configured to use claims-based authentication, the client interacts with the Security Token Service on the SharePoint farm to get a claims token. (See Configure claims authentication (SharePoint Server 2010) for more information.)

4. The BDC Client Runtime on client computers uses the data from the Business Data Connectivity service to connect to and execute operations on external systems for rich client access.

5. The Client Cache caches information from the Business Data Connectivity service and Secure Store Service that is needed to securely connect to external data. The cache is refreshed from the SharePoint farm to incorporate updated information.

6. The client Secure Store Service enables end users to configure their security credentials.

7. Microsoft Business Connectivity Services can pass credentials to databases and claims aware services.

Business Connectivity Services authentication overview

Microsoft Business Connectivity Services can be configured to pass authentication requests to external systems by using the following types of methods:

• Credentials These are typically in the form of name/password. Some external systems may also require additional credentials such as a personal identification number (PIN) value.

• Claims Security Assertion Markup Language (SAML) tickets can be passed to claims-aware services that supply external data.

Configuring Business Connectivity Services for credentials authentication

Microsoft Business Connectivity Services can use credentials that a user supplies to authenticate requests for external data. The following methods by which users can supply credentials for accessing external data are supported:

• Windows authentication:

  • Windows Challenge/Response (NTLM)

  • Microsoft Negotiate

• Authentication other than Windows

  • Forms-based

  • Digest

  • Basic

When configuring Microsoft Business Connectivity Services to pass credentials, the solution designer adds authentication-mode information to external content types. The authentication mode gives Microsoft Business Connectivity Services information about how to process an incoming authentication request from a user and map that request to a set of credentials that can be passed to the external content system. For example, an authentication mode could specify that the user’s credentials be passed directly through to the external data system. Alternatively, it could specify that the user’s credentials should be mapped to an account that is stored in a Secure Store Service which should then be passed to the external system.

You associate an authentication mode with an external content type in the following ways:

• When you create an external content type in Microsoft SharePoint Designer or Microsoft Visual Studio 2010.

• If the external system is a Web service, you can use the Microsoft Business Connectivity Services administration pages to specify the authentication mode.

• You can specify the authentication mode by directly editing the .XML file that defines the external content type.

The following table describes the authentication modes of the Microsoft Business Connectivity Services:

Authentication mode	Description
PassThrough	Passes the credentials of the logged-on user to the external system. This requires that the user’s credentials are known to the external system. Note If the Web application is not configured to authenticate with Windows credentials, the NT Authority/Anonymous Logon account is passed to the external system rather than the user's credentials. This mode is called User’s Identity in the Microsoft Business Connectivity Services administration pages and in SharePoint Designer 2010.
RevertToSelf	When the user is accessing external data from a Web browser, this mode ignores the user’s credentials and sends the application pool identity account under which the BCS runtime is running on the Web server to the external system. When the user is accessing external data from an Office client application, this mode is equivalent to PassThrough mode, because Microsoft Business Connectivity Services running on the client will be running under the user’s credentials. This mode is called BDC Identity in the Microsoft Business Connectivity Services administration pages and in SharePoint Designer 2010. Note By default, RevertToSelf mode is not enabled. You must use Windows PowerShell to enable RevertToSelf mode before you can create or import models that use RevertToSelf. For more information, see RevertToSelf authentication mode. RevertToSelf mode is not supported in hosted environments.
WindowsCredentials	For external Web services or databases, this mode uses a Secure Store Service to map the user’s credentials to a set of Windows credentials on the external system. This mode is called Impersonate Windows Identity in the Microsoft Business Connectivity Services administration pages and in SharePoint Designer 2010.
Credentials	For an external Web service, this mode uses a Secure Store Service to map the user’s credentials to a set of credentials that are supplied by a source other than Windows and that are used to access external data. The Web service should use basic or digest authentication when this mode is used. Important To help preserve security in this mode, we recommend that the connection between the Microsoft Business Connectivity Services and the external system should be secured by using Secure Sockets Layer (SSL) or Internet Protocol Security (IPSec). This mode is called Impersonate Custom Identity in the Microsoft Business Connectivity Services administration pages and in Office SharePoint Designer.
RDBCredentials	For an external database, this mode uses a Secure Store Service to map the user’s credentials to a set of credentials that are supplied by a source other than Windows. To help preserve security in this mode, we recommend that the connection between the Microsoft Business Connectivity Services and the external system should be secured by using Secure Sockets Layer (SSL) or IPSec. This mode is called Impersonate Custom Identity in the Microsoft Business Connectivity Services administration pages and in Office SharePoint Designer.
DigestCredentials	For a WCF Web service, this mode uses a Secure Store Service to map the user’s credentials to a set of credentials using Digest authentication. This mode is called Impersonate Custom Identity – Digest in the Microsoft Business Connectivity Services administration pages and in SharePoint Designer 2010.

The following illustration shows the Microsoft Business Connectivity Services authentication modes when it uses credentials.

• In PassThrough (User’s Identity) mode (A) the logged-on user’s credentials are passed directly to the external system.

• In RevertToSelf (BDC Identity) mode (B) the user’s logon credentials are replaced with the credentials of the process account under which Microsoft Business Connectivity Services is running, and those credentials are passed to the external system.

• Three modes use the Secure Store Service: WindowsCredentials (Impersonate Windows ID,) RdbCredentials (Impersonate Custom ID,) and Credentials. In those modes, the user’s credentials are mapped to a set of credentials for the external system and Microsoft Business Connectivity Services passes those credentials to the external system. Solution administrators can either map each user’s credentials to a unique account on the external system or they can map a set of authenticated users to a single group account.

Configuring Business Connectivity Services for claims-based authentication

Microsoft Business Connectivity Services can provide access to external data based on an incoming security tokens and it can pass security tokens to external systems. A security token is made up of a set of identity claims about a user, and the use of security tokens for authentication is called “claims-based authentication.” SharePoint Server includes a Security Token Service that issues security tokens.

The following illustration shows how the Security Token Service and the Secure Store Service work together in claims-based authentication:

1. A user tries an operation on an external list that is configured for claims authentication.

2. The client application requests a security token from the Security Token Service.

3. Based on the requesting user’s identity, the Security Token Service issues a security token that contains a set of claims and a target application identifier. The Security Token Service returns the security token to the client application.

4. The client passes the security token to the Secure Store Service.

5. The Secure Store Service evaluates the security token and uses the target application identifier to return a set of credentials that apply to the external system.

6. The client receives the credentials and passes them to the external system so that an operation (such as retrieving or updating external data) can be performed.

Business Connectivity Service permissions overview

Permissions in Microsoft Business Connectivity Services associate an individual account, group account, or claim with one or more permission levels on an object in a metadata store. By correctly setting permissions on objects in Microsoft Business Connectivity Services, you help enable solutions to securely incorporate external data. When planning a permissions strategy, we recommend that you give specific permissions to each user or group that needs it, in such a way that the credentials provide the least privilege needed to perform the needed tasks.

Warning

Properly setting permissions in Microsoft Business Connectivity Services is one element in an overall security strategy. Equally important is securing the data in external systems. How you do this depends on the security model and features of the external system and is beyond the scope of this article.

Note

Business Connectivity Services uses the permissions on the metadata objects and the permissions on the external system to determine authorization rules. For example, a security trimmer can keep external data from appearing in users' search results. However, if users somehow discover the URL to the trimmed external data, they can access the external data if they have the necessary permissions to the metadata object and the external system. The correct way to prevent users from accessing external data is to set the appropriate permissions both in Business Connectivity Services and in the external system.

What can permissions be set on?

Each instance of the Business Data Connectivity service (or, in the hosting case, each partition) contains a metadata store that includes all the models, external systems, external content types, methods, and method instances that have been defined for that store’s purpose. These objects exist in a hierarchy as depicted in the following illustration:

Note

In the previous hierarchy graphic, labels in parentheses are the names of objects as they are defined in the Microsoft Business Connectivity Services metadata schema. The labels that are not in parentheses are the names of each object as it appears in the user interface of the Business Data Connectivity service. For a full discussion of the Microsoft Business Connectivity Services metadata schema, along with walkthroughs of many development tasks, see the Microsoft SharePoint 2010 Software Development Kit (https://go.microsoft.com/fwlink/p/?LinkId=166117&clcid=0x409 ).

The hierarchy of objects in a metadata store determines which objects can propagate their permissions to other objects. In the illustration, each object on which permissions can be set, and optionally propagated, is shown with a solid line; each object that takes its permissions from its parent object is shown with a dotted line. For example, the illustration shows that an External System (LobSystem) can be secured by assigning permissions to it, but an Action cannot be assigned permissions directly. Objects that cannot be assigned permissions take the permissions of their parent object. For example, an Action takes the permissions of its parent External Content Type (Entity).

Security Note
When the permissions on an object in a metadata store are propagated, permission settings to all children of that item are replaced by the permissions of the propagating object. For example, if permissions are propagated from an External Content Type, all Methods and Method Instances of that External Content Type receive the new permissions.

Four permission levels can be set on the metadata store and the objects it contains:

• Edit

  Security Note
  The Edit permission should be considered highly privileged. With the Edit permission, a malicious user can steal credentials or corrupt a server farm. We recommend that, in a production system, you give Edit permission only to users whom you trust to have administrator-level permissions.

• Execute

• Selectable in clients

• Set permissions

The following table defines the meaning of these permissions on the various objects for which they can be set.

Object	Definition	Edit permissions	Execute permissions	Selectable in clients permissions	Set permissions permissions
Metadata store	The collection of XML files, stored in the Business Data Connectivity service, that each contain definitions of models, external content types, and external systems.	The user can create new external systems.	Although there is no “Execute” permission on the metadata store itself, this setting can be used to propagate Execute permissions to child objects in the metadata store.	Although there is no “Selectable in clients” permission on the metadata store itself, this setting can be used to propagate these permissions to child objects in the metadata store.	The user can set permissions on any object in the metadata store by propagating them from the metadata store.
Model	An XML file that contains sets of descriptions of one or more external content types, their related external systems, and information that is specific to the environment, such as authentication properties.	The user can edit the model file.	The “Execute” permission is not applicable to models.	The “Selectable in clients” permission is not applicable to models.	The user can set permissions on the model.
External system	The metadata definition of a supported source of data that can be modeled, such as a database, Web service, or .NET connectivity assembly.	The user can edit the external system. Setting this permission also makes the external system and any external system instances that it contains visible in SharePoint Designer.	Although there is no “Execute” permission on an external system itself, this setting can be used to propagate Execute permissions to child objects in the metadata store.	Although there is no “Selectable in clients” permission on an external system itself, this setting can be used to propagate these permissions to child objects in the metadata store.	The user can set permissions on the external system.
External content type	A reusable collection of metadata that defines a set of data from one or more external systems, the operations available on that data, and connectivity information related to that data.	Although there is no “Edit” permission on an external content type itself, this setting can be used to propagate these permissions to child objects in the metadata store.	The user can execute operations on the external content type.	The user can create external lists of the external content type.	The user can set permissions on the external content type.
Method	An operation related to an external content type.	The user can edit the method.	Although there is no “Execute” permission on a method itself, this setting can be used to propagate Execute permissions to child objects in the metadata store.	There is no “Selectable in clients” permission on a method.	The user can set permissions on the method.
Method instance	For a particular method, describes how to use a method by using a specific set of default values.	The user can edit the method instance.	The user can execute the method instance.	There is no “Selectable in clients” permission on a method instance.	The user can set permissions on the method instance.

Special permissions on the Business Data Connectivity service

Along with the general capabilities of setting permissions described earlier, there is a set of special permissions for the Business Data Connectivity service:

• Farm administrators have full permissions to the Business Data Connectivity service. This is necessary, for example, to be able to maintain or repair an instance of the service. However, be aware that the farm administrator does not have execute permissions on any object in the metadata store and this right must be given explicitly by an administrator of an instance of the Business Data Connectivity service if it is required.

• Windows PowerShell users are farm administrators and can run commands on the Business Data Connectivity service.

• Application pool accounts on front end servers have the same permissions to the Business Data Connectivity service as farm administrators. This permission is necessary to generate deployment packages based on Microsoft Business Connectivity Services.

• SharePoint Designer users should, in most cases, be given the following permissions on the whole metadata store: Edit, Execute, and Selectable in clients. SharePoint Designer users should not be given Set permissions permissions. If necessary, you can limit the permissions of the SharePoint Designer user to a subset of the metadata store.

  Warning

  To help ensure a secure solution, SharePoint Designer should be used to create external content types in a test environment in which Edit permissions can be assigned freely. When deploying the tested solution to a production environment, remove the edit permissions to help protect the integrity of the external data.

Common tasks and their related permissions

This section describes common tasks in the Business Data Connectivity service and the required permissions to perform them.

Task	Permissions
Create a new object in the metadata store	To create a new metadata object, a user must have edit permissions on the parent metadata object. For example, to create a new method in an external content type, a user must have permissions on the external content type. See the illustration earlier in this article for child/parent relationships among objects in the metadata store.
Delete an object from the metadata store	To delete a metadata object, a user must have edit permissions on that object. To delete an object and all its child objects (such as deleting an external content type and all its methods) the edit permission is also required on all the child objects.
Adding an external content type to a model	To add an external content type to a model, a user must have edit permissions on the model.
Importing models	To import a model to the metadata store, a user must have edit permissions on the metadata store. If explicit permissions are not assigned on the model, the user who imported it will be given edit permissions on the model.
Exporting models	To export a model from the metadata store, a user must have edit permissions on the model and on all external systems contained in the model.
Generating a deployment package	Deployment packages are generated by the application pool account that is used by the front-end server. This account has full permissions to the metadata store so that it can perform this task.
Setting initial permissions on the metadata store.	When an instance of the Business Data Connectivity service is first created, its metadata store is empty. The farm administrator has full permissions to the store and can set initial permissions.
Generate a deployment package from a consuming farm.	The Business Data Connectivity service application can be shared across server farms. In order to generate a deployment package from a consuming farm (the farm that connects to a remote location to use the Business Data Connectivity service application), the application pool account that is used by the front-end server of the consuming farm must have permissions to the metadata store on the publishing farm. For more information about how to assign permissions to the application pool account, see Set permissions to enable a consuming farm to generate a deployment package.

Securing Business Connectivity Services

This section discusses additional measures that can be used to help secure Business Connectivity Services

Service account

For security isolation, the Business Data Connectivity service application and the front-end server should not use the same service account.

Server to server communication

Securing the communication between the Business Data Connectivity service application and external systems helps ensure that sensitive data is not compromised. You need to use an encrypted communication channel to protect data that is sent between servers running SharePoint Server 2010 and external systems. Internet Protocol security (IPsec) is one method that can be used to help protect communication. The choice of which method to use depends on the specific communication channels you are securing and the benefits and tradeoffs that are most appropriate for your organization.

Applications that use FileBackedMetadataCatalog

For security reasons, RevertToSelf authentication mode is disabled on SharePoint Server 2010 by default. However, this does not prevent applications that use the FileBackedMetadataCatalog class from importing models and executing calls that use RevertToSelf authentication. This can result in elevating privileges for users by granting privileges to the application pool account. You should review all applications to ensure that they do not use FileBackedMetadataCatalog class and RevertToSelf authentication before installing them on a production system.

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Server 2010
Resource Center: What's New in Microsoft SharePoint Server 2010
Resource Center: Business Connectivity Services in SharePoint Server 2010