BI Service Applications in SharePoint 2010 – Authentication (Classic vs. Claims) and Identity Delegation (Kerberos) – Part 6

  • Article

Author: Chris Bailiss
Technical Reviewers (Kerberos/Claims): James Noyce, Paul Williams

Introduction

This post is part of a series of posts describing the authentication methods supported by the SharePoint 2010 Business Intelligence service applications. Please see Part 1 for an overview of this series of posts.

This post describes how to test that user identity is being delegated through the BI service applications in a web application utilising FBA-Claims. It also covers some differences in the functionality that is supported by FBA-Claims.

BI Service Application Tests in the Claims Web App – FBA-Claims

For a third time I’ll walk through each of the BI Service Applications tested previously – again accessing them in the claims web app, only this time authenticating as a forms based user (FBA-Claim).

To state the obvious, FBA-Claims have no associated Windows identity. This section will describe the consequences of this and how it can be worked around.

Excel Services

Accessing the test workbook created earlier in the Claims site allows the same test to be repeated:

C2WTS is now unable to obtain a windows security token and the connection to SQL Server fails. There is therefore now no way to delegate the user identity to the back-end. 

It is still possible to connect to the back-end using a credential stored in the Secure Store Service. This is configured on the connection properties in the Excel application:

Enter either a specific Secure Store Service ID (SSS ID) or select None to pick up a default credential configured in the Secure Store Service and Excel Services. The workbook can then connect to the SQL Server database using the stored, shared credential:

PerformancePoint Services

Accessing the test dashboard created earlier now results in:

As the error message helpfully explains, it has not been possible (for the C2WTS service) to obtain a windows identity from the non-windows claim.

To work around this again requires using a shared credential stored in the Secure Store Service. However, it is still possible to pass the identity into Analysis Services (albeit via a mechanism that is harder to work with in Analysis Services) using the PPS Data Connection Authentication option “Unattended Service Account and add authenticated user name in connection string”.

The dashboard then appears as:

The user name (in claims format) then appears in the Custom Data measure.

Reporting Services

Reporting Services was already configured in the previous section to work with a shared account. This continues to work with FBA-Claims:

PowerPivot for SharePoint

As described previously, PowerPivot for SharePoint works only with Classic-mode authentication.

Visio Services

Accessing the test web drawing created earlier now results in an error:

Again, this is due to there being no windows identity to authenticate to SQL Server with. Specifying a trusted shared account in the Secure Store Service allows the drawing to work, albeit again without the original user identity being delegated to the back-end:

It is worth noting that the Secure Store Service can only be used for web drawings that use an ODC file to specify the connection.

Is Claims Augmentation the Answer?

So, the FBA-Claims tests show that none of the key BI services are able to transition an FBA-Claim to a windows security token. 

This may seem surprising; since the C2WTS service can obtain a windows security token, provided it is presented with a UPN claim (see MSDN). This offers the theoretical possibility that adding a UPN claim into the set of claims might allow C2WTS to magically make the BI services work.

Well, it is possible to add additional claims using a Claims Augmenter (see MSDN), including adding the UPN claim:

Unfortunately, the BI service applications will only invoke the C2WTS for Windows-Claims. Each claim is tagged with the provider that issued it. This tag is immutable, so you cannot create a UPN claim from a claims augmenter that will be usable by SharePoint.

So, no, claims augmentation is not the answer :-(

[Aside: The custom membership provider, custom role provider and claims augmenter were contained in a single assembly for development purposes.  This assembly was deployed into the farm using a wsp solution, which dropped it into the WFE.  It was necessary to also deploy it manually into the GAC on the the application servers – without this the service apps were failing on these servers].

Continued...

Continue reading in Part 7.