Right now, the only game in town for accomplishing something like that that doesn’t involving coding or web services is Kerberos Delegation, which allows for user identities to be securely passed around from server to server. A big drawback to Kerberos, however, is the fact that it isn’t an Internet-friendly protocol and, in the Microsoft world, is tightly coupled to Active Directory. So to get this to work for external users, a product like Forefront Threat Management Gateway, the successor to ISA Server 2006, is typically deployed in front of SharePoint. TMG supports Kerberos Constrained Delegation, meaning users enter credentials to TMG via a form the credentials are authenticated against an Active Directory account, and TMG then proxies all internal connections for the user using Kerberos tickets. This approach has been around for a couple of years and it works fine.
But now, things are (of course) different with SharePoint 2010. For example:
- SharePoint 2010 introduces a new, standards-based approach to authentication using SAML 1.1 tokens. This opens up new possibilities for opening up SharePoint environments to external users and partner companies without having to provision accounts for them. Hopefully if you follow this blog, you’re well familiar with this. J
- PerformancePoint is now PerformancePoint Services, a Service Application within SharePoint 2010 that is natively “claims aware”.
- SharePoint 2010 includes the Claims to Windows Token Service (C2WTS), which magically translates SAML tokens to Kerberos Tickets. All that is required is a correctly populated UPN claim and, presumably, a corresponding AD account.
So taking the three above points into account, I wanted to see if it would be possible to configure Kerberos delegation for users authenticating via ADFS 2.0. This would enable, for example, a user who is part of a partner organization to sign into SharePoint using WS-Federation SSO and access a dashboard that contains only the data relevant to the user.
The Setup
Testing with Kerberos requires a multi-server environment. I had limited hardware to work with so I used the bare minimum: two virtual machines running on my laptop. All browser access was done from the laptop.
The logical authentication design is a modification on the model outlined in the TechNet article: Identity delegation for PerformancePoint Services. But instead of authenticating to the WFE with Kerberos, the idea here is to use SAML token generated by ADFS 2.0. ADFS 2.0 is configured to authenticate the user against an Active Directory account which exists in the same domain as the SharePoint server. The Relying Party Trust is configured to include the UPN claim in the SAML token. In SharePoint, the UPN claim type is defined as the Identity claim for the user. So in this example, I basically shift the Windows Authentication process over to ADFS. It’s nothing fancy.
I followed all the Kerberos setup steps described in Configuring Kerberos authentication: Step-by-step configuration. I then published a PerformancePoint dashboard with Data Source Settings set to “Per-user Identity”. On my claims-mode web application, I enabled both the Trusted Identity Provider (ADFS) and Windows authentication (Negotiate) so I could test both the “supported” authentication model as well as the SAML-based one.
When using Windows Authentication (Negotiate), I was able to confirm my test account’s identity was getting passed back to the virtual machine hosting Analysis Services.
So far so good! Kerberos authentication is online and working. Now let’s try it out with SAML claims from ADFS.
Delegation with SAML Claims: Initial Results
Long story short, it doesn’t work. As expected, I was able to access the dashboard, but PerformancePoint Services throws an error (Event ID: 1) and no data is loaded. Based on the error message, it looks like PerforamncePoint Services will not send a SAML token to C2WTS in cases where the UPN claim originates from an external identity provider. Bummer…
An exception occurred while running a report. The following details may help you to diagnose the problem:
Error Message: $Resources:ppsma.ServerCommon,ErrorCode_DataSourceCannotGetWindowsIdentityForNonWindowsClaim;
<br>
<br>
Contact the administrator for more details.
Dashboard Name:
Dashboard Item name:
Report Location: /analytics/Lists/PerformancePoint Content/2_.000
Request Duration: 57.77 ms
User: i:0e.t|adfs intranet|tnielsen@pbdev.local
Parameters:
Exception Message: $Resources:ppsma.ServerCommon,ErrorCode_DataSourceCannotGetWindowsIdentityForNonWindowsClaim;
Inner Exception Message:
Stack Trace: at Microsoft.PerformancePoint.Scorecards.Server.PmServer.ExecuteAnalyticReportWithParameters(RepositoryLocation analyticReportViewLocation, BIDataContainer biDataContainer)
at Microsoft.PerformancePoint.Analytics.ServerRendering.OLAPBase.OlapViewBaseControl.ExtractReportViewData()
at Microsoft.PerformancePoint.Analytics.ServerRendering.OLAPBase.OlapViewBaseControl.CreateRenderedView(StringBuilder sd)
at Microsoft.PerformancePoint.Scorecards.ServerRendering.NavigableControl.RenderControl(HtmlTextWriter writer)
PerformancePoint Services error code 20604.
Delegation with SAML Claims: A Workaround
Happily, there is a workaround and the technique fairly well known in the Business Intelligence community. Basically, it involves switching the authentication mode of the data connection object for a dashboard to “Unattended Service Account and add authenticated user name in connection string”. When doing this, the data is retrieved using a single connection account, but the user ID is passed in the <CustomData> element of a connection.
Some work needs to be done on the Analysis Services side to implement the security trimming, but it’s not too difficult…and it works. My colleague Brian Ringley recently posted on how to do this. Keep in mind that when using claims, the account ID in the user dimension will need to match the exact format of your SAML claim identifier, not the DOMAINsamAccountName format that Brian describes. In my case, this would be i:0e.t|adfs intranet|<User Principal Name Value>.
Conclusion
It’s a bit disappointing that Kerberos delegation doesn’t (appear to) work for PerformancePoint for users authenticated with an external SAML claims provider; especially since the C2WTS has, in theory, everything it needs to generate the ticket on the user’s behalf. Perhaps there’s something I missed here, this will be fixed in a later service pack, or maybe this behavior is “by design” due to security issues I haven’t thought through. However, it’s good to know a decent workaround exists that doesn’t involve network architecture changes such as introducing TMG.
As a side note, I’d be interesting to know if the next version of SQL Server (a.k.a “Denali”) will include support for SAML token authentication. It doesn’t look promising, though, seeing how there’s no mention of this in the current documentation.
