Claims Authentication and Reporting Services
SharePoint 2010 products support Claims Based Authentication. SQL Server 2008 R2 Reporting Services in SharePoint integrated mode will work with SharePoint Claims enabled Web application by using Trusted Account authentication and SharePoint User tokens. For more background information about Claims based authentication, see Claims-Based Identity Overview. For more information about SharePoint 2010 authentication, see Plan authentication methods.
The following are the basic steps that occur when a report server and the Reporting Services Proxy connect to a Claims enabled Web Front-end (WFE).
The claims enabled WFE performs the appropriate Claims authentication and using the SharePoint Secure Token Service, communicates the Claims token(s) to the Reporting Services proxy that is on the SharePoint WFE.
The Reporting Services Proxy on the WFE uses the Claims tokens to generate a SharePoint user token that it forwards to the Report Server.
The report server itself remains claims unaware and does not perform any claims specific authentication or conversion. It uses the SharePoint user token sent it by the Reporting Services Proxy.
Based on the SharePoint user token, the report server uses the local SharePoint object model to generate the correct SharePoint user context.
The report server sends the requested information, such as a rendered report, back to SharePoint using the appropriate SharePoint user context.
SharePoint 2010 lets users convert existing SharePoint 2010 Web applications to Claims based authentication. Web applications that use non-Windows authentication and were upgraded from an earlier version of SharePoint to SharePoint 2010 will have to be converted if Claims Authentication is desired.
For more information on Converting Web applications to claims authentication, see Configure forms-based authentication for a claims-based Web application (SharePoint Server 2010).
The following Reporting Services configuration changes are required to support Claims enabled web applications.
Configure the Reporting Services Service Account(s) to access the converted Web application. Use the Reporting Services Integration Web page in SharePoint Central Administration. When using a reporting services environment in a scale out deployment and the Report Server use different service accounts, use the Add Report Server to the Integration Web page in SharePoint Central Administration for each report server.
For existing Reporting Services subscriptions, use rs.exe and scripts with ChangeSubscriptionOwnerSOAP API to change the subscription owners to appropriate users supported by Claims authentication.
For existing model item security use Model Item Security web page or script with SetModelItemPolicies API to update the list of users that have Read Access on individual model items to users supported by Claims authentication.
Authentication Fallback behavior of the Reporting Services Add-in for SharePoint 2010 products
The Reporting Services integration page in SharePoint Central Administration allows the user to configure one authentication mode, either Trusted Account or Windows Authentication. However the SharePoint environment may contain web applications which each rely on different authentication types. For example one Web application could be configured for Claims Based authentication and a different Web application configured for Classic Mode authentication. The Reporting Services Proxy, that was installed by the add-in is flexible and can in some scenarios change authentication methods
If the reporting services integration was configured for Windows Authentication, the Reporting Services proxy has the ability to fallback to Trusted authentication the proxy detects a SharePoint web application that is configured for Claims Based Authentication.
The following table summarizes Reporting Services behavior based on the configured authentication for the Reporting Services Integration and a SharePoint Web application.
Reporting Services Integration Page
SharePoint 2010 Web application configuration
Classic Based Authentication
Claims Based Authentication
Classic Based Authentication
Claims Based Authentication
Yes. The Reporting Services proxy will fallback to use Trusted Account authentication.
The side effects of the fallback behavior are that in some circumstances, Windows Authentication is needed. For example if a report is using a data source that is configured for Windows integrated security you will see an error message similar to the following because the Reporting Services proxy detected the Web application was using Claims Authentication and the Proxy used the fallback logic and the session is in the Trusted Account context:
An error has occurred during report processing. (rsProcessingAborted)
Cannot impersonate user for data source 'MyDataSourceName'. (rsErrorImpersonatingUser)
This data source is configured to use Windows integrated security. Windows integrated security is either disabled for this report server or your report server is using Trusted Account mode. (rsWindowsIntegratedSecurityDisabled)
To work around this issue you need to modify the data source to use stored credentials.
The Reporting Services client applications: Report Builder, the Report Designer in Business Intelligence Development Studio, and Management Studio do not support connecting and authenticating with LiveID or SAML Claims based SharePoint Web applications. The clients can work with other forms of Claims Authentication because they use the Reporting Services authentication endpoint. The endpoint allows the clients to communicate to SharePoint through the same components used by ASP.NET forms authentication. SAML Claims and LiveID authentication work differently and are not supported by the Reporting Services clients.