Access denied when viewing PerformancePoint content via FBA (claims based authentication) on SharePoint 2010

Question

Can FBA logged in users view PerformancePoint content?

We have successfully implemented Forms Based Authentication (Claims Based Authentication Provider) in SharePoint 2010.

When logging in with Windows credentials, the dashboards are accessible and behave as expected. However, when authenticated via FBA, attempting to view any dashboard element (everything else works) results in an access denied error:

When viewing a single PerformancePoint report, ULS Viewer shows a couple of issues:

07/09/2013 11:22:59.68 w3wp.exe (0x17F8) 0x1E5C SharePoint Foundation General 8e2s Medium Unknown SPRequest error occurred. More information: 0x80070005 0441f0e6-02a3-40e4-ba36-9ca1a4396f4d

07/09/2013 11:22:59.68 w3wp.exe (0x17F8) 0x1E5C SharePoint Foundation General 72k8 High Failed to determine the setup path of the list schema for feature {481333E1-A246-4D89-AFAB-D18C6FE344CE}, list template 450. 0441f0e6-02a3-40e4-ba36-9ca1a4396f4d

07/09/2013 11:22:59.70 w3wp.exe (0x0F30) 0x28A4 PerformancePoint Service PerformancePoint Services ef8z Critical An exception occurred while rendering a Web control. The following diagnostic information might help to determine the cause of this problem: Microsoft.PerformancePoint.Scorecards.BpmException: There was a problem setting the item location URL. PerformancePoint Services error code 20700. 0441f0e6-02a3-40e4-ba36-9ca1a4396f4d

The event log also catches the following error (note the NT Authority\IUSR account which I assume is where things are going wrong):

Which brings me back to my question... Given that the site is working for Windows authenticated users, is there something additional that is necessary to get PerformancePoint dashboards working for forms-authenticated users?

Answer 1

Opened a support ticket with Microsoft. After much digging, our support technician helped us discover that the built-in FBA login page allowed the PerformancePoint content to be correctly displayed; the custom developed login page we were using was the culprit.

The offending code:

FormsAuthentication.SetAuthCookie("0#.f|fbamembershipprovider|" + USERNAME, false);

The working code:

Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.Current.SetPrincipalAndWriteSessionToken(
SPSecurityContext.SecurityTokenForFormsAuthentication(
    new Uri(SPContext.Current.Web.Url),
    "FBAMembershipProvider",
    "FBARoleProvider",
    USERNAME,
    PASSWORD,
    false)  
);