Monday, April 16, 2012

It’s Not Long Enough

For those whom have serviced calls about authentication in SharePoint 2010, a portion of your last two years may have been spent learning the broad range of changes that have come with the Federated and Claims Based models that are now part of authentication in SharePoint 2010.
One common scenario, especially for Forms Based Authentication sites (implemented with CBA) is how to extend the login window.

The Default – 10 Hours?

Once you switch (or initially create) a web application over to CBA and implement a Forms Based Authentication provider you might start to notice that the cookie window has a peculiar lifetime…it’s 10 hours for both Windows and Forms Based Authentication.
It’s worth noting that until you implement the FBA the cookie’s still behave similar to those in Classic authentication (expire at end of session).
The cookie is relatively easy to find (seen here with the Firefox Add-in Cookies Manager+).

Figure 1: Authentication Ticket from FBA Login

How to Extend It

It’s very likely there’s someone in your organization that either doesn’t like logging in, or isn’t very good at it. For these genre of users the new FBA behavior isn’t a boon and it’s only a matter of time before the conversation of extending the login windows comes up.
Strangely enough there’s not a ton of straightforward documentation (partly the reason for this post) or options to remedy this.

One of the easiest ways to extend this is by altering the configuration of the Secure Token Service with PowerShell. To be fair, it has a pretty big impact (farm wide) and introduces some other concerns. One of these is the fact that the user won’t be tasked with authenticating for the duration of the new extended window. While this sounds obvious (that’s the point right?) the fact that users are authenticating less often means that other actions (say in Active Directory or at application levels) like invalidating users or hooking/processing events at authentication time won’t be firing.

If you extend the window to say 30 days, it’s possible that users that you’re marking invalid may have access to systems who don’t check said flag (and focus simply on authorization…I mean that’s partly the raison d'être for CBA) for quite a bit longer than if you’d left it alone.

For sites that we’ve been asked to do this, we usually implement an HttpModule to inspect the user for any properties that are normally screened at authentication time so that we know we’re dealing with a valid user. So far this has seemed to mitigate the effects.

Ok, enough talk. You can see the existing farm level settings for the Secure Token Service with the following PowerShell command:

Get-SPSecurityTokenServiceConfig

That should yield the following output, notice that the Forms and Windows Token Lifetime are individual settings (both initially 10 hours) and can be set independently.

Figure 2: Secure Token Service Settings

You can change these settings by running the following commands for the Windows and Forms token lifetimes respectively:

Set-SPSecurityTokenServiceConfig –WindowsTokenLifetime [minutes]

Set-SPSecurityTokenServiceConfig –FormsTokenLifetime [minutes]

This is of course done with PowerShell, I haven’t seen a way to do so with the web.config for the service.
Once making the changes, they begin immediately (no need to recycle app pools or web servers). Your cookie should look like below (set to 30 hours as an example).

Figure 3: Extended FedAuth Cookie

I know it’s not ideal (has huge impact and raises other considerations), but it IS the most straightforward way of extending the cookie, and if it’s available, you should at least know about it.
Hope that helps, Tyler

Hello!If you use a Custom Login page you likely can get access to the FedAuth cookie in the Response object and forcibly change the expiration time. Of course, after user is authenticated. I described it in my post - SharePoint: How to change the expiration time of the FedAuth cookie. So, in this case you will never affect other applications.

About Me

Tyler Holmes is a Solutions Architect working in Portland, Oregon. He lives mostly in the MS tech stack and is currently treading the waters of Communication/Collaboration and Business Intelligence with off the shelf/open source technologies.