Why PowerPivot requires ‘classic-mode’ web applications

SharePoint 2010 has a new ‘claims-based’ authentication system that allows you to use federated identities with SharePoint. And there are certainly some customers that are excited to start playing around with this capability. That is neat and cool and all . . . but that isn’t the major reason why folks should be getting excited about ‘claims’. It is just a side-effect. The real reason why SharePoint uses claims is to bypass the Kerberos requirement within the farm. This is a huge benefit for SharePoint. In SharePoint 2007 once you grow beyond a single machine, then you must configure Kerberos between all of the servers – this quickly becomes a huge problem and limits both SharePoint adoption and its growth because many customers do not have the infrastructure needed to run Kerberos. But before you get too carried away with claims, particularly with PowerPivot, you have to remember two things: (a) PowerPivot only support Windows users and (b) we don’t support claims integration down to the client. The first one is easy to understand as SSAS only supports Windows credentials – and Excel Services uses that to establish the Windows identity for the connection. Having claims down to the client means that the user can perform one login to SharePoint – and have it be remembered for all future logins.

The second one (i.e. ‘b’ above) is a bit trickier and it is the core issue for this blog entry. In PowerPivot, when connecting through our front-end web services (aka, the PowerPivot Web Service, or PWS in our architectural design) the underlying protocol is the same as the one that earlier versions of Analysis Services used for the ‘data pump’ feature (http://technet.microsoft.com/en-us/library/cc917711.aspx). That protocol does not know about claims – it relies on getting a Windows identity.

The implications of this is when creating a SharePoint web application, you must ensure that you select the ‘classic-mode’ for the web application authentication:

If you select “claims-based’ then SharePoint will pop up the forms-based authentication dialog box when a client application that does not expose the user’s claims identity to SharePoint. SharePoint pops up the dialog box even if Windows is the authentication provider. The idea is that if the user is a Windows user, then they type their Windows user name and password into the FBA login dialog box. This is all well and cool – except for our front-end web service – it needs the Windows identity to continue. For backend web services such as the PSS (PowerPivot System Service) and the channel transport used by ECS (and others) to route requests to the PSS – they run perfectly fine. The claims identity flows with their WCF calls. This issue is between the client and the web application – how is the user’s identity established right at the front-door?

If you select ‘classic’ and you are coming in the front-door then the SharePoint infrastructure uses standard IIS capabilities to get the user’s identity and then translate that identity into a claims token. For our front-end web service, this means that the user’s Windows identity is moved up from the client to the IIS server, or IIS uses basic authentication, or some other IIS mapping is done to get to the Windows user.

Claims-based on the other hand tells the SharePoint infrastructure that the client will provide the claims identity directly. If it does not, then the SharePoint system has no option other than to ask the user to provide them which it does so by popping up the FBA login dialog box. But some systems, like our front-end web service, cannot respond to the login properly. If you select ‘claims-based’, then the PowerPivot front-end web service will return a ‘Too many automatic redirections were attempted. (System)’ error. Why is that? The issue is that since our service needs the user’s identity, the FBA dialog box will try to be rendered to try and get the user’s credentails. The FBA fails and our code asks for the user’s identity, then FBA fails, and the system keeps repeating until the ‘too many redirects’ error is returned.

One of my favorite jokes is “A man walks into a doctor’s office. He says ‘Doctor, doctor, my arm hurts when I move it like this!’ The doctor replies ‘Then don’t move it like that’ “ — Well . . . maybe it isn’t too funny, but gosh it applies in lots of places. And one of those places is here. To re-phrase: “Doctor, Doctor, my PowerPivot web application tells me that it has too many redirects” – the doctor replies “Then don’t do that – set it for classic mode.” Any funnier now?

Enjoy.