This brings me to the second part – Authentication. I am using “PassThrough” authentication in the above BDC App. This means, I am logged in as “MyDomain\Sahil”, and “MyDomain\Sahil” has access to the database NorthWind. Also, Sahil has access to the BDC application. So when “Sahil” tries accessing the BDC, it works. But, when Search (which is running as “MySharePointMachine\Local Service” tries accessing BDC, it bombs).
So I need to fix it. Here is how -
- Create a new account for search.
- Change the default content access account to that account. This can be done under search settings.
- Change search crawler account to that account. This can be done under operations\services on the server\office sharepoint server search
- Give this account access to NorthwindTraders
- Make this account have edit, execute & select permissions on the Northwindtraders business data catalog. Copy permissions to appropriate decendants.
The other option I have is to use a different kind of authentication (but that has it’s own ramifications).
Configuration of the Business Data Catalog
Actually, there is no configuration to be done for the Business Data Catalog itself to interact with Single Sign-On. However, for every Application Definition where Single Sign-On is used, a LobSystemInstance node has to be added to the LobSystemInstances collection. Every LobSystemInstance specifies an “access point – in terms of connection and security information – to the LOB system, the Microsoft SQL Server database in this example scenario.
<LobSystemInstance Name=”Demo LOBDatabase”>
<Property Name=”AuthenticationMode” Type=”System.String”>RdbCredentials</Property>
<Property Name=”DatabaseAccessProvider” Type=”System.String”>SqlServer</Property>
<Property Name=”RdbConnection Data Source” Type=”System.String”>moss-sql01</Property>
<Property Name=”RdbConnection Initial Catalog” Type=”System.String”>SQLAuthDemo</Property>
<Property Name=”RdbConnection Integrated Security” Type=”System.String”>false</Property>
<Property Name=”RdbConnection Pooling” Type=”System.String”>false</Property>
<Property Name=”SsoApplicationId” Type=”System.String”>SQLAuthDemoSSOApp</Property>
<Property Name=”SsoProviderImplementation” Type=”System.String”>Microsoft.SharePoint.Portal.SingleSignon.SpsSsoProvider, Microsoft.SharePoint.Portal.SingleSignon, Version=188.8.131.52, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Property>
In order to use Single Sign-On, please make sure that besides the regular connection information, the following properties are set:
RdbConnection Integrated Security: Tells the Business Data Catalog explicitly to not use integrated security.
SsoApplicationId: Name of the Single Sign-On application as specified in Step 6.5 of the Single Sign-On setup.
SsoProviderImplementation: Default pluggable implementation of the SharePoint SsoProvider.
Besides of the above configuration which is done directly in the application definition file, there are no further actions required to enable Business Data Catalog to connect using Single Sign-On services.
As discussed in the Business Data Catalog Authentication topic, there are three authentication modes you can use with SSO:
- WindowsCredentials (Database and Web Service Systems)Microsoft Office SharePoint Server 2007 authenticates by using Windows credentials from its default single sign-on (SSO) service. Use this mode if your database server or Web Service uses Windows authentication. You need to set up SSO for this mode.
- 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. Use this mode if your database server uses Database Credentials. For example if your SQL Server uses SQL Server authentication instead of Windows authentication. You need to set up SSO for this mode.
- 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. Use this mode if your Web Service uses credentials other than Windows credentials. You need to set up SSO for this mode.
To use SSO instead of PassThrough authentication when connecting to the AdventureWorks2000 database, use the following procedure. Note that the SQL Server has to be set up to use Windows authentication in this case.
The Business Data Catalog supports two authentication models:
- Trusted Subsystem
- Impersonation and Delegation
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.
The table below summarizes when you should use each authentication mode and provides links to any samples currently available in the SDK.
|Authentication Mode||Applies to||Scenarios||Sample|
|PassThrough||Databases and Web Services||Use this mode if you are in a testing environment with a single-box configuration (Database server and SharePoint Server on the same box) or if Kerberos Delegation is enabled in your domain. You might also use it if the destination server or the Web Service uses anonymous authentication or SSL connections.||Step 1: Connect to the AdventureWorks2000 Database|
|RevertToSelf||Databases and Web Services|
|WindowsCredentials||Databases and Web Services||Use this mode if your database server or Web Service uses Windows authentication. You need to set up SSO for this mode.||Step 7 (Optional): Use Single Sign-On to Connect to the AdventureWorks2000 Database|
|RdbCredentials||Database Systems only||Use this mode if your database server uses Database Credentials. For example if your SQL Server uses SQL Server authentication instead of Windows authentication. You need to set up SSO for this mode.|
|Credentials||Web Service Systems only||Use this mode if your Web Service uses credentials other than Windows credentials You need to set up SSO for this mode.|
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, specify the single sign-on application that contains the credentials.
- Define a UsernameCredentialFilter and PasswordCredentialFilter, and associate each with an input parameter.