Implementing BDC Security Options

This section introduces the security options that are available when you use the BDC-in particular, authentication, authorization, and access control. Authentication is the process by which you verify that a user is who he or she claims to be; authorization is the process of finding out whether the user, once authenticated, is permitted to access the data; and access control is how you will manage access to the business data exposed using the BDC.

To understand the BDC security options, it is important to understand the roles of the application pool and the search content access accounts. The following list summarizes key points to keep in mind about the BDC:

  • When the business data is exposed through the BDC on a Web page, the BDC runs within the Internet Information Services (IIS) worker process (w3wp.exe), and therefore, it's using the IIS application pool user account.

  • When the BDC is used for crawling to index content to which it is connecting, it runs in the filter daemon process (msadmn.exe), and therefore, it's using the search content source account. Unlike the NTFS file system, which consistently uses the same protocol for authentication and authorization, business applications will either use Windows authentication or a proprietary method of authentication and authorization. Hence, when the BDC indexes the business application, it cannot acquire security information from the back end. Therefore, if a business application is crawled, result sets from a keyword search will not take into account any access control.

The rest of this section details the BDC security options when data is exposed using the BDC APIs.

Authentication Methods

The two authentication models in BDC are as follows:

  • Trusted Subsystem The SharePoint Server 2007 Web front-end (WFE) servers control authentication and authorization and retrieve data from the business application servers using a fixed identity. SharePoint Server 2007 servers primarily supports the trusted system model for access services and resources. In the trusted system model, a system account is used to access services and resources on behalf of all authenticated users so that administrators do not have to specify access for each user. The fixed identity is the application pool ID or a group ID retrieved from the Single Sign-On (SSO) database.

  • Impersonation and Delegation In this authentication model, the business application delegates authentication to the WFEs and the application pool ID impersonates the user. The application pool ID then connects to the business application servers on the user's behalf by using Kerberos or SSO, or by passing the user's name as a parameter. Use this model if you want application-level authorization of the business data.

Security Alert 

In any system where credentials are sent between servers, an attacker can possibly compromise the security solution. Ensure that you secure your infrastructure appropriately-for example, by using Kerberos, Secure Sockets Layer (SSL), or IPSec.

Table 12-1 summarizes the reasons for choosing one authentication model over another.

Table 12-1: Authentication Models: Trusted Subsystem vs. Impersonation and Delegation
Open table as spreadsheet

Trusted subsystem

Impersonation and delegation

Connection pooling



Reduces licensing costs on the back-end LOB system



Less complex



Provides a single model for authorization



Support scenarios in which there is per-user authorization at the back end.



Enable auditing at the back end.



There are four authentication modes, which are defined on the LOBSystemInstance XML tag in the ADF:

  • PassThrough The user's authentication information is passed through to the back-end server, which makes this the least desirable option from a security and administrator viewpoint.

  • RevertToSelf If a user logs on with Windows authentication, the application pool ID is used to impersonate that particular account when using SharePoint Server 2007. RevertToSelf authentication allows SharePoint Server 2007 to revert back to the IIS application pool ID before requesting data from the back-end LOB system. This is the default option if no authentication mode is specified.

  • Credentials If the data source is a database, SharePoint Server 2007 authenticates by using database credentials from the default SSO service. The XML tag RdbCredentials can also be used for this authentication mode. If the data source is a Web service, non-Windows credentials from the SSO are used for basic or digest authentication, depending on the configuration of the Web service.

  • WindowsCredentials SharePoint Server 2007 authenticates by using Microsoft Windows credentials from its default SSO service.

Table 12-2 shows the relationship between the authentication models and authentication modes.

Table 12-2: Relationship Between Authentication Models and Modes
Open table as spreadsheet


Trusted subsystem model

Impersonation and delegation model







Credentials, Windows Credentials (SSO group account)



Credentials, Windows Credentials (SSO user account)




There are two methods of controlling user access to data managed by the BDC:

  • Back-end authorization, if the business application can perform per-user authorization.

  • Middle-tier authorization, which provides central security and auditing abilities using the BDC permission settings and SharePoint list/library security configuration options.

Central Security and Auditing

After the ADF is imported into the BDC, you can manage permissions centrally using the Shared Services Administration Web page to define permissions at the BDC level, application level, or entity level. You cannot define permissions at the entity instance level. If you add a business data column to a list or library, a copy of the data is placed in that list or library and you exploit the item-level security available in lists and libraries.

In the ADF, if an entity contains an Audit property set to true, an entry is written to the SSP audit log every time one of the entity's methods is executed. If a business data column is added to a list or library, the default auditing features in SharePoint Server 2007 are available to you.

Each object in the BDC hierarchy of metadata objects (LobSystem, Entity, Method, MethodInstance, and so on) has an access control list (ACL) that specifies which principals have which rights on the object. Out of the 13 metadata objects, only LobSystem, Entity, Method, and MethodInstance have their own individually controllable ACL. These objects are referred to as individually securable metadata objects. Other metadata objects inherit the ACL from their immediate parent and are referred to as access-controlled metadata objects.

Table 12-3 shows the rights that can be set by the administrator or someone with the Manage Permissions right.

Table 12-3: BDC Permissions
Open table as spreadsheet


Applies to



Access-controlled metadata objects

Person with this permission can perform the following actions:

  • * Update

  • * Delete

  • * Create child object

  • * Add property

  • * Remove property

  • * Clear property

  • * Add localized display name

  • * Remove localized display name

  • * Clear localized display name

Set Permissions

Individually securable metadata objects

Person with this permission can manage BDC permissions

Execute (View)

MethodInstance objects

Person with this permission can execute the MethodInstance via various run-time API calls, that is, they can view the instances of a entity that are returned from a finder method.

Selectable in Clients

Application and Entity objects

Persons with this permission can use the business data picker to configure Web Parts and lists to use the BDC.

To set permission at the BDC level, follow these steps:

  1. On the SharePoint 3.0 Central Administration Web site, in the left navigation pane, click the name of the Shared Services Provider where you want to import the metadata package.

  2. In the Business Data Catalog section, click Business Data Catalog permissions, and then on the Manage Permissions: Business Data Catalog page, click Add Users/Groups.

  3. On the Add Users/Groups page, shown in Figure 12-3, enter the appropriate users or groups and assign the appropriate permissions. You can configure rights to managing the BDC that are independent of the rights in the rest of the Shared Services Provider. Permissions set at this level can copied to any LOB system and entity imported into the BDC.

  4. Click OK.

image from book
Figure 12-3: Add Users/Groups-Business Data Catalog page


When the SSP is created, the userid of the person who creates the SSP is given Edit, Execute, Selectable In Clients and Set Permission rights. Subsequently, if any users are given rights to the SSP Web site, by default they do not receive any rights to the BDC. Hence, only the SSP creator is able to manipulate the BDC or see data returned from the data sources. Therefore, using the procedure above, you should give appropriate BDC permissions to a group of users, who are to administer the BDC, and you should give the Execute (View) right to, for example, the Domain Users or some similar group. Ensure that your crawl account also has the Execute (View) right.

Microsoft Office Sharepoint Server 2007 Administrator's Companion
MicrosoftВ® Office SharePointВ® Server 2007 Administrators Companion
ISBN: 0735622825
EAN: 2147483647
Year: 2004
Pages: 299

Similar book on Amazon
Microsoft Office SharePoint Server 2007 Best Practices
Microsoft Office SharePoint Server 2007 Best Practices
Microsoft SharePoint 2010 Administrator's Companion
Microsoft SharePoint 2010 Administrator's Companion
Professional SharePoint 2010 Administration
Professional SharePoint 2010 Administration
Inside Microsoft  Office SharePoint  Server 2007
Inside Microsoft Office SharePoint Server 2007 © 2008-2017.
If you may any questions please contact us: