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

  • 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 my claims-mode web application – “claims”. The functionality of the BI services accessed via this web application are described in the following posts.

Claims Web Application

After getting the portal web application running, I configured a second web application – “claims”. The claims web app uses the Claims-mode authentication provider.

The claims web app utilises the same set of service applications as the portal web app. This means it will pick up the existing working set of service applications and their Kerberos-related configuration.

Note - even though this web application uses claims, Kerberos is still relevant. This is because the back-end SQL Server instances are not claims-aware – they are geared to work with windows authentication. For outbound authentication to the back-end, SharePoint uses the Claims to Windows Token Service (C2WTS), part of the Windows Identity Foundation, to obtain a windows identity (Kerberos ticket) from the set of claims. To do this, the C2WTS performs a Kerberos Constrained Delegation Protocol Transition – hence Kerberos is still relevant.

The claims web app supports both Windows-Claims and Forms Based Authentication (FBA-Claims).

You may expect that a user authenticated with a Windows-Claim will be able to access the same functionality from the SharePoint BI service applications as a user authenticated into the Portal web app using Classic-mode windows authentication. This is in fact not always true and varies by service-application as I’ll describe in the next couple of posts.

FBA-Claims do not have a windows identity associated with them, so will obviously not be able to delegate a windows identity. Could C2WTS help here? Not really, as I’ll also describe in a later post.

Upon navigating to the claims URL, the default screen is presented where the user is asked to select the authentication method:

If Windows Authentication is selected, the user is automatically logged in based on a Windows-Claim based on their active directory account.

If Forms Authentication is selected, the user is redirected to a second login screen:

These FBA tests used a simple custom membership provider and a simple custom role provider. References:

  • System.Web.Security.MembershipProvider Class - MSDN
  • System.Web.Security.RoleProvider Class - MSDN
  • Claims Walkthrough: Creating Forms-Based Authentication for Claims-Based SharePoint 2010 Web Applications Using Custom Membership and Role Providers – MSDN

A simple Claim Viewer web part was also created, which lists the users claims. A sample of a similar viewer can be found at MSDN. 

When logged in with a Windows Claim, the following set of claims is displayed:

The UPN claim (https://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn) is worth noting. The UPN claim is used by the Claims to Windows Token Service (C2WTS) to obtain a windows security token that can be delegated to systems that aren’t claims aware such as the SQL Server Relational Database Engine and Analysis Services.

When logged in with an FBA Claim, the following set of claims is displayed:

Continued...

Continue reading in Part 5.