ContextSessionSecurityToken being overwritten when second user logs in

Question

I have an issue occurring in a single production environment that is very head scratching.

You have two users, A and B. User A logs in, everything works fine. User B logs in, and after user B logs in, user A now has the same security token as user B.

Our WIF setup is fairly standard, we inject some custom claims on the token, but everything else looks standard as far as how the token is being created and stored(Handled by WIF).

Feel like I may be running into some weird edge case with WIF that I am not familiar with

Update: Both A and B can be on separate machines, or separate browsers on the same machine.

Where we get the token when requesting a service

if (HttpContext.Current == null)
    return null;

if (HttpContext.Current.Cache == null)
    return null;

if (FederatedAuthentication.SessionAuthenticationModule == null)
    return null;

if (FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken == null)
    return null;

var sessionToken = FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken;
if (sessionToken.ClaimsPrincipal == null)
    throw new InvalidOperationException("The ClaimsPrincipal property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object is null");
if (sessionToken.ClaimsPrincipal.Identities == null)
    throw new InvalidOperationException("The ClaimsPrincipal.Identities sub-property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object is null");
if (sessionToken.ClaimsPrincipal.Identities.Count == 0)
    throw new InvalidOperationException("The ClaimsPrincipal.Identities sub-property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object has no identities");
if (sessionToken.ClaimsPrincipal.Identities[0] == null)
    throw new InvalidOperationException("The first identity in the ClaimsPrincipal.Identities sub-property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object is null");
if (sessionToken.ClaimsPrincipal.Identities[0].Claims == null)
    throw new InvalidOperationException("The first identity in the ClaimsPrincipal.Identities sub-property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object as a null Claims property");

return TokenUtility.GetDelegatedToken(IssuedTokenTypes.UserProfile | IssuedTokenTypes.AccountPermissions, sessionToken);

If I add logging here I can see the sessionToken.ClaimsPrincipal.Identity.Name differs from the name it is supposed to be at this point.

You mean A logs in on a PC, B uses the same PC, same browser session or what? — rbrayb, Feb 20 '13 at 18:37
Not possible if the site is browsed from two different machines/browsers. Tokens are posted to the site and persisted in a cookie. There is no way for this to be shared among users unless you do something obvliously wrong like storing data in static variables. — Wiktor Zychla, Feb 20 '13 at 18:39
@nzpcmad you can be on two different browsers on the same machine. You can be on two separate machines. — jcolebrand, Feb 20 '13 at 18:41
@WiktorZychla Yup, you're tracking our train of thought. And yet, somehow, the session information is getting overwritten when no such code exists in our codebase. — jcolebrand, Feb 20 '13 at 18:41
@jcolebrand: it is your first wif-enabled application or nth+1 with n already done and working? It is almost impossible to say what is wrong with no code to inspect and after two years with wif I am 100% sure that typical scenarios always work flawlessly. — Wiktor Zychla, Feb 20 '13 at 18:58
@WiktorZychla This exact setup runs correctly in production in a separate environment, and also runs correcttly in our dev, and test environments. Let me edit with some code — Aaron M, Feb 20 '13 at 19:04
What IP are you using? How are you checking that both users have the same token? Do you get the same result if you remove the custom claim code? — rbrayb, Feb 20 '13 at 19:09
It looks like we were able to resolve the issue by turning off output caching and kernalmodecaching. The relevant section was — Aaron M, Feb 20 '13 at 20:39

score 1 · Answer 1 · answered Jan 26 '14 at 09:02

1

Are your relying party and STS(WIF) Server hosted on same IIS using same Application pool? If yes then try by using different application pool as worker process sometimes use to mess up the things. Hope this will help you.

answered Jan 26 '14 at 09:02

Krishan Kumar Gorav

47
1
9

score 0 · Answer 2 · answered Apr 01 '13 at 17:29

I have seen a similar issue. We resolved it be changing the cashing on IIS and in the code. The cashing was causing the security to seem to be messed up but the server was just storing the last result of the html that was generated, making it look like user A was logged in and not user B. Hope this helps some.

score 0 · Answer 3 · answered Mar 05 '14 at 20:53

It would help if you posted some additional information regarding both any web configuration settings as well as IIS configuration and .NET Framework version. To me, this sounds like an application pool issue but that is with extremely limited knowledge of your system. If the application pool identity is custom then of course accessing the same user, unless localsystem or impersonation is set. If this is not the issue check your authorization settings, and make sure anonynous, and basic are turned off, or whatever it may be that your application requires.

ContextSessionSecurityToken being overwritten when second user logs in

3 Answers3