#formsauthentication

Recently we deployed our application using Forms Authentication and after a few days of use we discovered that our Event Viewer is littered with Informational messages relating to 4005.

Event code: 4005

Event message: Forms authentication failed for the request. Reason: The ticket supplied has expired.

Event time: 1/19/2012 7:16:33 AM

Event time (UTC): 1/19/2012 12:16:33 PM

Event ID: 3446144ae1ee46efadd90542175e24fc

Event sequence: 48901

Event occurrence: 1452

Event detail code: 50202

  Application information:

Application domain: /LM/W3SVC/1/ROOT-1-129713452236000000

Trust level: Full

Application Virtual Path: /

Application Path: E:\MobileBanking\Version 1.0.0.0\

Machine name: M1CUONLINE01

  Process information:

Process ID: 1348

Process name: w3wp.exe

Account name: IIS APPPOOL\MobileBanking

  Request information:

Request URL: https://mobile.members1st.org:443/account/logon

Request path: /account/logon

User host address: 166.248.33.121

User:

Is authenticated: False

Authentication Type:

Thread account name: IIS APPPOOL\MobileBanking

  Name to authenticate:

  Custom event details:

After a bit of research this error occurs when your users authenticates to your site and then attempts to request a resource after their cookie has expired.  (this also assumes you are on a single server configuration, if not you might be experiencing an issue with machinekeys)

If you wish to suppress these informational messages you can alter your web.config to the following which simply removes the rule for 4005

<healthMonitoring enabled="true"> <eventMappings> <!-- Event Mappings for 0-4004 and 4006 to infinite, skipping 4005, see last attribute of these entries --> <add name="Failure Audits 1" type="System.Web.Management.WebFailureAuditEvent,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" startEventCode="0" endEventCode="4004"/> <add name="Failure Audits 2" type="System.Web.Management.WebFailureAuditEvent,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" startEventCode="4006" endEventCode="2147483647"/> </eventMappings> <rules> <!-- REMOVE ITEMS NOTED BY MAX --> <remove name="Failure Audits Default"/> <!-- ADD Back 4006 to 4011 with these two entries, skipping over 4005 --> <add name="Failure Audits Default 1" eventName="Failure Audits 1" provider="EventLogProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00" custom=""/> <add name="Failure Audits Default 2" eventName="Failure Audits 2" provider="EventLogProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00" custom=""/> </rules> </healthMonitoring>

Background If you have been using Client Application Settings (CAS), like me, you are well aware that it is a great framework.  But like anything else, it has a few limitations.  In this case we are referring to an issue that you may encounter when working in a Single Sign-On (SSO) environment.

The issue materializes when you have an authenticated user that requests a page on your site where your Profile information is provided via CAS.  The reason this is an issue is that ASP.NET, when using Forms authentication, will populate the HttpContext.Current.User.Identity property with a FormsIdentity.  However, with CAS you are going to need a ClientFormsIdentity.  You are going to need to craft some magic to get that FormsIdentity into a ClientFormsIdentity and attached to Thread.CurrentPrincipal.

Scenario So, lets set some assumptions here for what we are working with:

You have written an ASP.NET web service which uses Forms authentication

Your authentication is provided by an SSO service, which also has CAS enabled

An authenticated client calls your service.

Our task is to get the User's Profile (settings), which are provided by CAS, to be populated.

The Issue CAS Settings (Profile) properties are associated with the current Thread.  The problem with this is that ASP.NET does not impersonate the logged in user.  This is also an older feature of .NET which will require your Application Pool in IIS to be configured to  use the Classic pipeline - which we are not going to do.

For some applications this may not even be viable, such as WCF DataServices which requires the integrated pipeline.  So, what we need to do is take our authenticated FormsIdentity, turn it into a ClientFormsIdentity and attach it to Thread.CurrentPrincipal.

An additional note is that the CAS settings will not load unless the current Thread's principal derrives from the ClientFormsIdentity,  which is the identity type set when you use CAS's Membership.ValidateUser.   This method sets the Thread.CurrentPrincipal property.

The Solution To solve this, we will need to take our HttpContext.Current.User.Identity and snag the authentication cookies from it.

var identity = HttpContext.Current.User.Identity as FormsIdentity; CookieContainer container = new CookieContainer(); foreach (String key in HttpContext.Current.Request.Cookies) { var cookie = HttpContext.Current.Request.Cookies[key]; container.Add(new Cookie(cookie.Name, cookie.Value, cookie.Path, String.Empty)); }

This simply creates a new CookieContainer which we can use with CAS.  After we have this, it is as easy as simply creating our new identity and silently re-authenticating it.

ClientFormsIdentity ident = new ClientFormsIdentity(string.Empty, string.Empty, Membership.Provider, "ClientForms", true, container);

Thread.CurrentPrincipal = new ClientRolePrincipal(ident); ident.RevalidateUser();