Manage authentication for the Business Data Catalog

Article
01/10/2017

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

Topic Last Modified: 2016-11-14

The Business Data Catalog for Microsoft Office SharePoint Server 2007 supports two authentication models and three authentication modes that use single sign-on (SSO) to store user credentials.

In this article:

Select a preferred authentication model and authentication mode
Configure accounts for the back-end application
Enable and configure the single sign-on service
Create and configure enterprise application definitions
Modify and import the application definition for the application
Task Requirements

To manage authentication for the Business Data Catalog by using SSO, you complete the steps in this document for each database or Web service that you are integrating into your deployment.

Select a preferred authentication model and authentication mode

Applications in the Business Data Catalog can use several different authentication modes that can use one of two distinct authentication models.

Select an authentication model

The authentication models used by the Business Data Catalog are conceptual and do not correspond to any specific XML or other configuration setting. You implement an authentication model by configuring the application definition XML file to use a particular account to connect to the back-end server.

The Business Data Catalog supports the following 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. 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. Each model supports several authentication modes that can be used in different integration scenarios.

The Trusted Subsystem model offers the following advantages:

Database connection pooling
Less complex administration
Administrators of the back-end server for the application only have to manage permissions for a single account

The Trusted Subsystem is a good choice for new deployments. Application administrators do not have to configure authorization permissions on the back-end server for a large number of users. Instead, they can configure one account for each application and then configure authorization in Office SharePoint Server.

The Trusted Subsystem model uses a service account or database account associated with a group account in the enterprise application definition.

The Impersonation and Delegation model offers the following advantages:

Auditing at the back-end server
Per-user authorization at the back-end server without any additional configuration

Impersonation and Delegation can be a good choice for an existing application that is configured for per-user authorization. After the Impersonation and Delegation model is configured, each user continues to be authenticated using the configuration on the back-end application. This can be cumbersome when an organization is administering several line-of-business applications integrated into a deployment of Office SharePoint Server, each with its own authorization settings that must be managed on an ongoing basis. Unless auditing at the back-end server is required, it is often a good practice to use the Impersonation and Delegation model only during initial deployment until a Trusted Subsystem model can be configured.

The Impersonation and Delegation model uses an individual Windows user account and either a database user account (for databases only) or a Forms-based authentication user (for Web services only) associated with an individual account.

Select and configure an authentication mode

The following table describes the authentication modes supported by the Business Data Catalog and whether or not the mode uses SSO.

Authentication mode	Description	Uses SSO
PassThrough	Uses the credentials of the logged-on user to authenticate to the application on the back-end server. This mode is only available for the Impersonation and Delegation authentication model. PassThrough authentication requires that Kerberos delegation is enabled.	No
RevertToSelf	Uses the application pool identity account to authenticate users to the back-end server. Because a service account is always used instead of an individual account, RevertToSelf uses the Trusted Subsystem authentication model.	No
WindowsCredentials	Used for both Web services and databases. The Business Data Catalog impersonates a Windows user account with credentials from an enterprise application definition and performs Windows authentication.	Yes
Credentials	Used for Web services that use basic or digest authentication instead of Windows authentication. To help preserve security, when using the Credentials authentication mode it is highly recommended that the channel between the Business Data Catalog and the back-end server is secured by using Secure Sockets Layer (SSL) or Internet Protocol Security (IPSec).	Yes
RdbCredentials	Used only for back-end databases. The Business Data Catalog uses credentials from an enterprise application definition for authentication.	Yes

Most of these modes use SSO to store credentials for the application, using either an individual or group identity configured as an enterprise application definition. The PassThrough mode uses the credentials of the logged-on user, and the RevertToSelf mode uses the application pool identity account to authenticate users.

For all of the SSO authentication modes, the enterprise application definition uses a group account for the Trusted Subsystem model and an individual account for the Impersonation and Delegation model. For more information about the enterprise application definition, see the “Create and configure enterprise application definitions” section in this document.

The authentication mode that you select affects the accounts or credentials that you configure on your back-end server, and the settings for SSO. The properties that you must configure for the application definition XML file are described in the “Modify and import the application definition XML file” section later in this document.

For more information about authentication models and authentication modes, see Business Data Catalog authentication (https://go.microsoft.com/fwlink/?LinkID=100498&clcid=0x409).

Configure accounts for the application

Before configuring SSO or the application definition XML file for the application, you configure the authorization permissions for one or more credentials for the back-end server:

If you are using the Trusted Subsystem authentication model, you only need to configure a single account or set of credentials on the application.
If you are using the Impersonation and Delegation authentication model, you need to configure authorization for every credential that the Business Data Catalog impersonates from an SSO group account. If an application is already in use by your organization, the necessary credentials may already have been configured and you can skip this step.

Accounts are configured within the database or Web service, and configuration details depend upon the specific permissions of the application.

Enable and configure the Single Sign-on service

If you selected an authentication mode for the Business Data Catalog that uses SSO, you must enable and configure the Microsoft Single Sign-On service (SSOSrv) on all front-end Web servers in the farm. If you are also using search for the Business Data Catalog, you must enable SSOrv on the index server.

The logon account for the service must be:

A domain user account. It cannot be a group account.
An Office SharePoint Server farm account.
A member of the local Administrators group on the encryption-key server. (The encryption-key server is the first server on which you start SSOSrv.)
A member of the Security Administrators role and db_creator role on the computer running Microsoft SQL Server.
Either the same account as the SSO administrator account, or a member of the group account that is the SSO administrator account.

After configuring the SSO service, you configure additional settings on the Central Administration page. Server settings for SSO include account information for a separate SSO administrator account, the SSO database server and server name, and time-out and audit log settings.

The user or group that you specify as the SSO administrator account must be:

Either a Windows global group or an individual user account. This account cannot be a domain local group account or a distribution list.
The same account as the Single Sign-on service account, if a user is specified. If a group is specified, the Single Sign-on service account must be a member of that group.
The same account as the configuration account for SSO, if a user is specified. If a group is specified, the configuration account for SSO must be a member of that group.
A member of the SharePoint Farm Administrators group.

For more information about enabling and activating the Single Sign-on service, see Configure and start the Microsoft Single Sign-On service. For more information about configuring the Single Sign-on service, see Configure single sign-on (Office SharePoint Server).

Create and configure enterprise application definitions

After you configure the Single Sign-on service, you must create and configure enterprise application definitions for your line-of-business applications. You create one enterprise application definition for each stored credential used by your line-of-business applications, databases, and Web services. Typically, you create one enterprise application definition for each application or service, though if you have multiple applications that use the same set of credentials you need only one enterprise application definition that can be used to connect to all applications that use those credentials.

Note

An enterprise application definition for SSO is not the same thing as the application definition XML file that is imported to the Business Data Catalog for each application or service. You must create an enterprise application definition and separately refer to that enterprise application definition in the application definition XML file.

After you create an enterprise application definition, you must configure account information for the enterprise application definitions. You must be logged on to the server as a local administrator to complete this procedure.

For more information about creating enterprise application definitions, see Create enterprise application definition for the Business Data Catalog. For more information about configuring enterprise application definitions, see Configure enterprise application definition for the Business Data Catalog.

Modify and import the application definition XML file

After you configure SSO and create and configure enterprise application definitions, you must modify the application definition to include the authentication mode for the application, the implementation for the ISsoProvider interface used by the application, and the enterprise application ID for the application. These properties are configured in the LOBSystemInstance object in the application definition XML file.

You can also modify other properties for the application. For a table that shows the full list of properties available for configuring authentication of both databases and Web services, see LOBSystemInstance (https://go.microsoft.com/fwlink/?LinkId=124545&clcid=0x409). Samples are also provided.

Before you can use the authentication settings for the Business Data Catalog, you must import the application definition XML file to the Business Data Catalog.

For more information about creating, modifying, and importing application definitions for the Business Data Catalog, see Manage application definitions.

Common authoring tasks for application definition XML files are described in the following subsections:

Configuring SSO authentication for a database
Configuring SSO authentication for a Web service
Configuring the SSO Provider for the application
Configuring RevertToSelf authentication
Configuring PassThrough authentication
Configuring application-level authentication for the application

Configuring SSO authentication for a database

To use SSO with database systems, the following properties are required:

AuthenticationMode for the LOBSystemInstance object is set to WindowsCredentials or RdbCredentials.
SsoProviderImplementation is set to the fully-qualified name of the ISsoProvider interface.

Note

If a third-party ISsoProvider interface is being used instead of the Office SharePoint Server ISsoProvider interface, then you must include the fully-qualified name for that provider.
SsoApplicationId is set to the value of the enterprise application ID for the application. You provided the name for the enterprise application definition when you created it.

Configuring SSO authentication for a Web service

To use SSO with Web service systems, the following properties are required:

WebServiceAuthenticationMode for the LOBSystemInstance object is set to WindowsCredentials or Credentials.
SsoProviderImplementation is set to the fully-qualified name of the ISsoProvider interface.

Note

If a third-party ISsoProvider interface is being used instead of the Office SharePoint Server ISsoProvider interface, then you must include the fully-qualified name for that provider.
WebServiceSsoApplicationId is set to the value of the enterprise application ID for the application.

Configuring the SSO provider for the application

Line-of-business applications that use SSO to authenticate users can set the SsoProviderImplementation property and the ISsoProvider interface to use any third-party SSO provider. To use an SSO provider other than the Office SharePoint Server SSO provider, you must configure that provider and then include the fully-qualified name for the provider in the application definition for this property. For more information, see ISsoProvider Members (https://go.microsoft.com/fwlink/?LinkId=124546&clcid=0x409).

Configuring RevertToSelf authentication for the application

Instead of using SSO, you can use the RevertToSelf authentication mode to configure the application to run as the application pool account identity and authenticate using the individual permissions of each user to the application. To use the RevertToSelf authentication mode, set the authentication property as follows:

To authenticate to a database, set the AuthenticationMode property for the LOBSystemInstance object to RevertToSelf.
To authenticate to a Web service, set the WebServiceAuthenticationMode property for the LOBSystemInstance object to RevertToSelf.

Configuring PassThrough authentication for the application

PassThrough authentication also foregoes using SSO to store accounts, and instead authenticates each user directly using the permissions of each account in the back-end application. To use the PassThrough authentication mode, set the authentication property as follows:

To authenticate to a database, set the AuthenticationMode property for the LOBSystemInstance object to PassThrough.
To authenticate to a Web service, set the WebServiceAuthenticationMode property for the LOBSystemInstance object to PassThrough.

Configuring application-level authentication for the application

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:

In the SecondarySsoApplicationId property of the LobSystemInstance object, specify the SSO application that contains the credentials.
Define the UsernameCredentialFilter and PasswordCredentialFilter properties, and associate each with an input parameter.

Configure anonymous access

The 2007 Microsoft Office Servers Service Pack 1 adds a new AllowAnonymousExecute property for the application definition to enable anonymous access of business data in business data Web Parts. Setting the value of this property to true enables anonymous access. Following is the XML for the property:

<Properties>

<Property Name="AllowAnonymousExecute" Type="System.Boolean">true</Property>

</Properties>

To enable anonymous access to data in a Business Data List Web Part or Business Data Item Web Part, add this property to the method instance used by the Web Part.

For example, to enable anonymous users to execute the ArtistRead method instance for a Business Data Item Web Part displaying information about a musical artist:

<MethodInstance Type="SpecificFinder" ReturnParameterName="ArtistRead" Name="ArtistRead">