Business Data Catalog Authentication

The Business Data Catalog 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. Typically you would choose this model for the following reasons:

• Offers database connection pooling.

• Reduces licensing costs on the back-end server.

• Is less complex.

• The group that owns and manages the back-end server gives access to one account that they manage.

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 choose this model for the following reasons:

• To enable auditing at the back-end server.

• If there is per-user authorization at the back-end server.

Authentication Modes

The following authentication modes are available when you use the Business Data Catalog to connect to a database or Web service.

Pass-Through (Database and Web Service Systems)

Pass-through authentication refers to the ability of the operating system to pass a client's authentication information to the back-end server. The Business Data Catalog supports pass-through authentication for both database and Web service connections. When you use pass-through authentication, you simply authenticate as the identity of the end user.

When the Business Data Catalog is accessed from a Web page, it runs in the Microsoft Internet Information Services (IIS) worker process, w3wp.exe. The identity of this process is the IIS application pool account impersonating the logged-on user. To avoid losing the logged-on user’s identity when the Business Data Catalog authenticates to the back-end server, you must enable Kerberos delegation between the server running IIS and the other computer. Kerberos delegation enables a receiving server to send the authentication request to the proper location.

When the Business Data Catalog 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.

A drawback to using pass-through authentication is that 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—private—information in addition to a user name and password), you cannot use pass-through authentication.

Despite these drawbacks, simplicity of use makes pass-through authentication a good candidate for use in a testing environment. You might also use it if the destination server uses anonymous authentication or SSL connections.

RevertToSelf (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 allows you to revert this impersonation and authenticate as the underlying account that is configured for the IIS Application Pool.

WindowsCredentials (Database and Web Service Systems)

Microsoft Office SharePoint Server 2007 authenticates by using Microsoft Windows credentials from its default single sign-on (SSO) service.

RdbCredentials (Database Systems Only)

In RdbCredentials mode, Office SharePoint Server 2007 authenticates by using database credentials from its default SSO service. Office SharePoint Server 2007 adds the database credentials to the connection string and transmits the credentials to the database server.

Credentials (Web Service Systems Only)

Office SharePoint Server 2007 authenticates Web service systems by using credentials other than those from Windows Authentication from its default SSO 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 SSL or IPSec or both to secure communication between the Web services server and the server running the Business Data Catalog.

Summary

The table below summarizes when you should use each authentication mode and provides links to any samples currently available in the SDK.

Authentication Modes and Authentication Patterns

The following table shows which authentication pattern each of the authentication modes takes.

Application-Level Authentication

The Business Data Catalog also supports a secondary, application-level authentication. This authentication is used in addition to the primary authentication configured for the system. It is particularly useful in situations where a back-end application needs security credentials to be passed in the method calls for authorizing users, for example. To enable application-level authentication, take the following steps.

1. In the SecondarySsoApplicationId property of the LobSystemInstance, specify the single sign-on application that contains the credentials.

2. Define a UsernameCredentialFilter and PasswordCredentialFilter, and associate each with an input parameter.

See Also

Concepts

Business Data Catalog Authorization

Other Resources

Business Data Catalog Samples