We’re using the Windows Identity Foundation to implement a Single Sign-On solution for our application. The problem I’m encountering is that the FedAuth cookie isn’t expiring when I think it should on the Relying Party side.
The FedAuth cookie isn’t being destroying until approximately five minutes after its ValidTo time. For testing purposes I have the token lifetime and session set to timeout after ten minutes.
<sessionState timeout="10" mode="SQLServer" sqlConnectionString="..." />
<securityTokenHandlers>
<add type="Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<sessionTokenRequirement lifetime="00:10" />
</add>
</securityTokenHandlers>
We’ve implemented our own SessionAuthenticationModule because we’re using sliding sessions. The code was taken pretty much verbatim from Programming Windows Identity Foundation but I don’t think that’s the problem as I’ve tried commenting out the code in the SessionSecurityTokenReceived event and I’m seeing the same behavior, but just for completeness.
DateTime now = DateTime.UtcNow;
DateTime validFrom = e.SessionToken.ValidFrom;
DateTime validTo = e.SessionToken.ValidTo;
double tokenLifetime = (validTo - validFrom).TotalMinutes;
if( now < validTo && now > validFrom.AddMinutes( tokenLifetime / 2 ) )
{
SessionAuthenticationModule sam = sender as SessionAuthenticationModule;
e.SessionToken = sam.CreateSessionSecurityToken(
e.SessionToken.ClaimsPrincipal, e.SessionToken.Context,
now, now.AddMinutes( tokenLifetime ), e.SessionToken.IsPersistent );
e.ReissueCookie = true;
}
If I sign into the app at 10:00am while debug the above code I can see the validTo value is 10:10am. I then let the app sit for eleven minutes and click on another link. In debugging the above I see that the value of now (10:11am) is indeed > validTo (10:10am) so the token expiration is not updated. At this point I would expect the SAM to destroy the FedAuth cookie. However, the FedAuth cookie is not destroyed, the value of Request.IsAuthenticated is still true (due to the presence of the cookie I’m assuming) and the user continues to access the application. It isn’t until ~10:15am when I actually see the cookie being expired (using Fiddler).
I’m at a loss as to why the FedAuth cookie isn’t being destroyed on the first access after the validTo time has expired. I can fudge it by setting my expiration times to be five minutes less than what I really want them to be, but I’d prefer to understand why I’m seeing this behavior.
This happens because there is a clock skew which by default I is set to 5 minutes. Typically clock skew is used to mitigate clock synchronization among servers (in this case servers of the same farm). If you want to disable or decrease that value you can do it by setting (from the top of my head)
FederatedAuthentication.ServiceConfiuration.MaxClockSkew = TimeSpan.FromSeconds(10);Just make sure that server clocks are 100% synchronized