Business Data Connectivity Service Authentication (original) (raw)
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Business Data Connectivity Service Authentication
- Article
- 07/24/2014
In this article
Applies to: SharePoint Server 2010
In this article
Authentication Modes
Authentication Patterns for the Authentication Modes
Application-Level Authentication
The Business Data Connectivity (BDC) service supports two authentication models:
- Trusted Subsystem
- Impersonation and Delegation
In the Trusted Subsystem model, the middle tier (usually the Web server) authenticates to the back-end server as a fixed identity. Choose the Trusted Subsystem model for the following reasons:
- The group that owns and manages the back-end server gives access to one account that they manage.
- It offers connection pooling.
- It reduces licensing costs on the back-end server.
- It is less complex.
In the Impersonation and Delegation model, the client delegates authentication to the middle tier, which impersonates the client and authenticates to the back-end on the client's behalf. You would use this model for the following reasons:
- To accommodate the back-end server requirement for per-user authorization
- To enable auditing at the back-end server
Authentication Modes
The following authentication modes are available when you use the BDC to connect to a database or Web service.
Note
To determine which authentication pattern to use for each mode, see Authentication Patterns for the Authentication Modes .
Pass-Through Authentication (Database and Web Service Systems)
Pass-through authentication is the ability of the operating system to pass a client's authentication information to the back-end server. BDC supports pass-through authentication for both database and Web service connections. When you use pass-through authentication, you authenticate as the identity of the logged on user.
When BDC is accessed from a Web page, it runs in the Internet Information Services (IIS) worker process, w3wp.exe, in the web front end server. The identity of this process is the IIS application pool account but the thread that is used to service the request impersonates the logged-on user. To avoid losing the logged-on user's identity when BDC authenticates to the back-end server, you must enable Kerberos delegation between the server that is running IIS and the other computer. Kerberos delegation enables a receiving server to send the authentication request to the correct location.
When BDC is used for crawling, it runs in the filter daemon process, mssdmn.exe. To access the back-end content source, the threads in the filter daemon process impersonate as the content access account associated with that back-end content source.
However, when pass-through authentication is used, the operating system exposes only the user name and password. Therefore, if a company uses two-factor authentication (that is, users are required to have some specific or private information in addition to a user name and password), pass-through authentication will not work.
Despite these drawbacks, simplicity of use makes pass-through authentication a good candidate for use in a testing environment, or if the destination server uses anonymous authentication.
RevertToSelf Authentication (Database and Web Service Systems)
If a user logs on with Windows authentication, IIS impersonates that particular account. So while IIS runs under the application pool identity, it impersonates the logged-on user, and the request runs under the user's impersonation before it is passed forward.
RevertToSelf authentication enables you to revert this impersonation and authenticate as the underlying account that is configured for the IIS application pool.
Warning
If custom code uses the RevertToSelf method for authentication, it can grant users system-level privileges on the back-end servers by granting privileges to the application pool identity. Therefore, you should not run any custom code on a production system until it is thoroughly tested.
WindowsCredentials (Database and Web Service Systems)
Microsoft SharePoint Server 2010 authenticates by using Windows credentials obtained from its default Secure Store Service.
RdbCredentials (Database Systems Only)
In RdbCredentials mode, SharePoint Server 2010 authenticates by using database credentials from its default Secure Store Service. SharePoint Server adds the database credentials to the connection string and transmits the credentials to the database server.
Credentials (Web Service Systems Only)
SharePoint Server 2010 authenticates Web service systems by using credentials other than those from Windows authentication from its default Secure Store Service. These credentials are used for basic or digest authentication, depending on the configuration of the Web services server. Because basic and digest authentication do not adequately protect credentials, you should use Secure Sockets Layer (SSL), Internet Protocol security (IPsec), or both to help secure communication between the Web services server and the server that is running BDC.
DigestCredentials (WCF Web Service Systems Only)
With DigestCredentials authentication mode, SharePoint Server 2010 uses the default Secure Store Service to map the user’s credentials to credentials other than those used for Windows authentication. The mapped credentials are used for digest authentication. Because digest authentication does not adequately protect credentials, you should use Secure Sockets Layer (SSL), Internet Protocol security (IPsec), or both to help secure communication between the WCF Web services server and the server that is running BDC.
Summary
Table 1 summarizes when to use each authentication mode and provides links to any samples that are currently available in the SharePoint 2010 SDK
| Authentication Mode | Applies To | Scenarios for Use |
|---|---|---|
| PassThrough | Databases and Web services | Use in a testing environment with a "single-box" configuration (database server and server running SharePoint Server on the same computer) or if Kerberos delegation is enabled in your domain. Can also use it if the destination server or the Web service uses anonymous authentication or SSL connections. |
| RevertToSelf | Databases and Web services | Use if you need to revert the impersonation and authenticate as the underlying account that is configured for the IIS application pool. |
| WindowsCredentials | Databases and Web services | Use if your database server or Web service uses Windows authentication. You need to set up Secure Store Service for this mode. |
| RdbCredentials | Database systems only | Use if your database server uses database credentials; for example, if your server that is running SQL Server uses SQL Server authentication instead of Windows authentication. You have to set up Secure Store Service for this mode. |
| Credentials | Web service systems only | Use if your Web service uses credentials other than Windows credentials. You have to set up Secure Store Service for this mode. |
| DigestCredentials | WCF Web service systems only | Use if your WCF Web service uses credentials other than Windows credentials for digest authentication. You have to set up Secure Store Service for this mode. |
Authentication Patterns for the Authentication Modes
The following table shows the authentication pattern each authentication mode takes.
| Pattern / Mode | PassThrough | RevertToSelf | Credentials, DigestCredentials, RdbCredentials, WindowsCredentials (Secure Store Individual Application) | Credentials, DigestCredentials, RdbCredentials, WindowsCredentials (Secure Store Group Application) |
|---|---|---|---|---|
| Trusted Subsystem | Yes | Yes | ||
| Impersonation and Delegation | Yes | Yes |
Application-Level Authentication
BDC also supports a secondary, application-level authentication that is used in addition to the primary authentication configured for the system. It is particularly useful in situations where a back-end application requires security credentials to be passed in the method calls for authorizing users.
You can enable application-level authentication by defining filters in the BDC model, namely the user name, password, SSOTicket, and UserContext filters. For more information about these filters, see Types of Filters Supported by the Business Data Connectivity Service.
The following shows how to enable application-level authentication by adding the user name and password filters to the BDC model.
To enable application-level authentication
- In the SecondarySsoApplicationId property of the LobSystemInstance, specify the Secure Store application that contains the credentials.
- Define a UsernameCredentialFilter and PasswordCredentialFilter, and associate each with an input parameter.