Authorization Failures with Claims-Based Authentication in SharePoint 2010

Scot Hillier

by Scot Hillier on 10/24/2010

Share this:
Print

Article Details

Date Revised:
11/23/2015

Applies to:
Article, Content Type, EDITORIAL USE ONLY


Originally Published 10/25/2010 and reproduced here for reference

As more organizations roll out SharePoint 2010 and make use of the new Claims Mode for authentication, I am seeing a very particular issue with authorization based on claims. In particular, users are being granted access to sites or resources by administrators, but still receiving "Access Denied" when attempting to access the resource. This occurs under a very particular, but increasingly common, set of circumstances.

1. The organization has a Claims-Mode Web Application using Windows, FBA, or both.

2. The organization wants to perform authorization using a custom claim generated by a custom claims provider

Let's look at a specific example of the issue starting with some background.

Background

I have a custom claims provider that issues additional claims to a user when they log in to SharePoint 2010. The additional claims are created based on the user's membership in SharePoint Audiences. The following image shows a subset of the claims for a user in which you can see the claim for membership in the "All Site Users" and "Developers" audiences.

When additional claims are created in this way, they may be used to grant access to resources in SharePoint. This is done by using the People Picker to select the claim value and grant access much as you would for an Active Directory account. The following image shows the People Picker resolving the "Developers" audience to grant access.

When the People Picker is used to grant access in this way, any user having the audience claim value "Developers" will have access to the designated resource. This is a very useful way to perform authorization for both standard SharePoint resources and custom SharePoint applications.

The Problem

Now that you understand the basics, consider the following scenario:

1. A user tries to access a SharePoint site

2. The user receives Access Denied

3. The user contacts the site owner and asks for permission

4. The site owner adds the user to the "Developers" audience and then picks the "Developers" group from the People Picker to grant access to the site. Since the user is now a member of the "Developers" audience, they should have access to the site. The key here is that the user did not already have the Developers audience claim in their token.

5. The site owner tells the user to try and access the site again

6. The user still receives Access Denied

7. Frustration ensues. Foul language is used. The IT staff is told that SharePoint is broken.

Why did this happen? It happens because the claims token has a default lifetime of 10 hrs. This means that the token is only built once every 10 hrs and then cached. This cached token is used for all subsequent requests. So the end user will not really be able to access the site until tomorrow (assuming they work an 8-hour day). Very annoying.

Note that this situation only occurs when you are using custom claims for authorization. If access was granted based on the user's account name or membership in an AD group, the access would have required only a logout and a login. Why? Because these claims already exist in the user's token.

The Fix

Many people are under the impression that simply clearing the browser cache or deleting cookies will cause the claims token to be rebuilt. So they tell the user to perform these actions, but access is still not granted.

The SharePoint 2010 Security Token Service (STS) maintains a session in which the same token is reused. This session defaults to 10 hrs and is on the server. Therefore, no amount of browser manipulation will end the session including an explicit sign out from SharePoint. The only way for a session to end is through a timeout or an IISRESET.

Fortunately, there is a pretty good solution. You can change the value of the session timeout using a PowerShell script. There are separate lifetime values for both Windows and FBA tokens. The following script sets both values to 60 minutes.

$sts = Get-SPSecurityTokenServiceConfig
$sts.WindowsTokenLifetime = (New-TimeSpan –minutes 60)
$sts.FormsTokenLifetime = (New-TimeSpan -minutes 60)
$sts.Update()
iisreset

Changing the timeout value will ease the problem, but you can never eliminate the issue. The only way to effectively eliminate the problem is to set the session value to be a ridiculously small value like 1 minute. This, however, would create inefficiencies in the STS, which may result in noticeable login delays during heavy loads.

Along with any technical change, organizations should provide some education to end users regarding authorization under this scenario. Perhaps the timeout could be reduced to 1 hour, but users should also be informed that any authorization changes could take an hour to propogate.

 


Topic: Article

Sign in with

Or register