The following sections introduce the security options that are available when you use the BCS—authentication,
authorization, and access control. Authentication is the process of
verifying 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 managing access to
the business data exposed using the BCS.
There
are two scenarios to consider with BCS: The first is the SharePoint
2010 use of BCS, exposing information on Web pages; the second is the
use of BCS in the Office client applications. Figure 1 shows the three major components, the Office client, SharePoint 2010, and external data sources.
Each lock in Figure 1 identifies a form of authentication as follows.
Lock 1 Logging on to your computer using your Windows credentials.
Lock 2
The authentication by Internet Information Services (IIS) on the
SharePoint 2010 Web front-end (WFE) server. In many SharePoint
implementations, if your SharePoint site is classified in the browser’s
intranet zone and uses integrated authentication, you are not prompted
for credentials. In such a configuration, your Windows credentials are
used to authenticate you. When the SharePoint site is configured for
forms-based authentication (FBA), IIS will prompt for your credentials.
Lock 3
The additional authentication required when an Office application such
as Outlook 2010 is configured to display contact information from a
Customer Relationship Management (CRM) or Enterprise Resource Planning
(ERP) system.
Lock 4
Authentication from SharePoint 2010 to the external data sources via
integrated authentication using Kerberos to flow the credentials across
multiple systems, Secure Store Services (SSS), Security Assertion Markup
Language (SAML) claims, or token-based authentication.
Locks 3 and 4
represent the additional security requirements that an external data
source may impose. This is a very common scenario for business data,
because of the administrative implications of aggregating data from
external data sources when building dashboards in SharePoint 2010, which
makes lock 4 of particular interest.
To understand the BCS SharePoint 2010 security
options, it is important to understand the roles of the application
pool and the search content access accounts. The following list
summarizes main points to keep in mind about the BCS.
When the business data
is exposed through the BCS on a Web page, the BDC runtime runs within
an IIS worker process (W3wp.exe), and therefore it is using the IIS
application pool credentials for that worker process.
When
the BCS is used for crawling, it runs in the filter daemon process
(Msadmn.exe), and therefore it is 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
configured at the source.
The following sections explain the BCS security options when data is exposed using the BCS interfaces.
1. Authentication Modes
The following are the two authentication modes in BCS.
Trusted subsystem
The SharePoint 2010 WFE servers control authentication and
authorization and retrieve data from the external system using a fixed
identity. SharePoint 2010 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 SSS database. If the external system is
configured to use identify federation authentication, the user’s
identity is passed to the Secure Token Service (STS) to obtain the user’s token or claim.
Impersonation and delegation
In this authentication model, the external system delegates
authentication to the WFEs, and the application pool ID impersonates the
user. The application pool ID then connects to the external system on
the user’s behalf by using Kerberos or SSS, or by passing the user’s
name as a parameter. Use this model if you want application-level
authorization of the business data.
Note:
SECURITY ALERT
In any system in which 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 Internet Protocol Security (IPSec).
The BCS
authentication mechanism uses either credentials, in the form of a user
name and password, or claims-based authentication in the following
modes.
PassThrough
The user’s authentication information is passed by the BDC runtime
through to the back-end system. This mode will always incur a double hop
unless SharePoint 2010 and the external system are installed on the
same computer, which usually only occurs in a development, prototyping,
or demonstration environment. In most installations, Kerberos is needed
to use this method with Windows authentication; otherwise, a login
failed message is displayed. In the Central Administration website and
in SharePoint Designer 2010, this mode is called User’s Identity.
RevertToSelf
If a user logs on with Windows authentication, the BDC runtime will use
the application pool ID to impersonate that particular user.
RevertToSelf authentication allows SharePoint 2010 to revert back to the
IIS application pool ID before requesting data from the external
system. In External Lists, this means the application pool for the
content page; for timed workflows, it means the process that runs the
workflow; and so on. The application pool of a SharePoint farm is a
highly privileged account, and Microsoft does not recommend using
RevertToSelf authentication in a production environment. If you used
RevertToSelf in SharePoint Server 2007, then during the upgrade process,
you should review the use of this authentication mode. In the Central
Administration website and in SharePoint Designer 2010, this mode is
called BDC Identity.
1818Credentials
The user’s identity is matched in SSS to the external system and
retrieves the individual or group credentials that should be used to
access the external system. These credentials are passed to the BDC
runtime and are used to access the external system. If the data source
is a database, SharePoint 2010 authenticates by using Windows or
database (custom) identities from the SSS. If the data source is a Web
service, non-Windows (custom) identities from the SSS are used for basic
or digest authentication, depending on the configuration of the Web
service. To use this mode in the Central Administration website or in
SharePoint Designer 2010, use either Impersonate Windows Identity or
Impersonate Custom Identity.
Note:
For an organization that has
its own single sign-on or secure token services and does not want to use
the SharePoint 2010 SSS or STS, SharePoint 2010 provides an application
interface to connect such a system to BCS.
|
Many Web 2.0 applications such as Windows Live ID, Yahoo! BBAuth, Google Account Authentication API, and Netflix with OAuth use Identity
Delegation. You can use these Web 2.0 applications as BCS external
systems. The Model for solutions based on data from these Web 2.0
applications cannot be created using SharePoint Designer but will need
to be created by a developer using Visual Studio.
|
|
Any person who can
create or edit RevertToSelf models can make themselves administrators of
SharePoint. In SharePoint Server 2007, this was not a big security
issue, because you could only upload the Model file using the Central
Administration website, and most people who could access SharePoint
Central Administration to complete this task were SharePoint farm
administrators anyway. Now that more people can upload model files using
SharePoint Designer, however, this is more of a security risk.
Therefore, RevertToSelf authentication is disabled by default in
SharePoint 2010. When a user tries to import or change the
authentication mode to RevertToSelf, an error message displays. The
error message that displays when using SharePoint Designer is shown in Figure 2.
Microsoft recommends strict
limits on the use of RevertToSelf authentication mode. If you use it at
all in a production environment, make sure that ALL of the following
conditions are true.
You are using SharePoint Foundation 2010, because it does not support the SSS application. You do not have resources to create a custom SSS. You trust all of the people who use SharePoint Designer as completely as if they were SharePoint administrators. The
application pool account is locked down so that the attach surface
exposed to a malicious user of SharePoint Designer is limited.
RevertToSelf can be turned on by code or by using Windows PowerShell as shown in the following example, where the variable BCSName is the name of your BCS application.
$bcs = Get-SPServiceApplication | where {$_.displayname -eq $BCSname};
$bcs.RevertToSelfAllowed = $True;
The RevertToSelf property
only affects the importing of new models or modifying an existing model
to using this authentication mode.
|
2. Authorization
There are two methods of controlling user access to data managed by the BCS.
Back-end authorization, if the business application can perform per-user authorization
Middle-tier authorization, which provides central security and auditing abilities using the BCS permission settings and SharePoint list/library security configuration options
After the Model file is
imported into the BCS, you can manage permissions centrally using the
BCS administration Web page to define permissions on objects in the
metadata store for a specific BCS application, or at the BDC Model,
external system level, or ECT level. These objects you can secure using
the Central Administration website or through the use of Windows
PowerShell, are referred to as “individually securable metadata
objects.” You cannot define permissions at the item level in an External
List. However, if you add an External Data Column to a list or library,
a copy of the data is placed in that list or library, and therefore you
can exploit the item-level security available in those lists and
libraries.
In the BDC Model, if an ECT
contains an Audit property set to True, an entry is written to the audit
log every time one of the ECT’s methods is executed. If an External
Data Column is added to a list or library, then the ECT method used to
copy the external data to the list or library will result in an entry in
the audit log, and thereafter, when the list or library is accessed, no
entry is created in the audit log—only the default auditing features in
SharePoint 2010 are available.
Each object has an access
control list (ACL) that specifies which user, group, or claim has which
rights on the object. Objects that are not individually securable
metadata objects inherit the ACL
from their immediate parent and are referred to as “access-controlled
metadata objects.” Depending on the object for which the user or group
is being granted permissions, the permission level specifies the actions
that the user or group can take on that object. All permissions on
objects in the BCS can be set using the following values: Edit, Execute, Selectable In Clients, and Set Permissions, as shown in Table 1.
Table 1. Business Connectivity Service Permissions
| PERMISSION | APPLIES TO | DESCRIPTION |
|---|
| Edit | Access-controlled metadata objects | User 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
Give Edit rights to administrators and users who use SharePoint Designer. |
| Set Permissions | Individually securable metadata objects | User
with this permission can manage BCS permissions on the object. This
permission is usually only given to BCS service application
administrators. |
| Execute | ECT, Method Instance | User
with this permission can execute operations via various runtime API
calls; that is, they can view the data of an ECT returned from a finder
method. In most scenarios, you would assign this right to all users who
have access to SharePoint. |
| Selectable In Clients | ECT | User
with this permission can use the external data picker to configure Web
Parts and lists and create External Lists. This permission should be
available to administrators and users who design solutions using the
browser or SharePoint Designer. |
