CODEWITHSUNDEEP
c#.netwif
Aaron M
Aaron M

Reputation: 2563

ContextSessionSecurityToken being overwritten when second user logs in

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.

Upvotes: 10

Views: 844

Answers (3)

Anthony Mason
Anthony Mason

Reputation: 175

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.

Upvotes: 0

Krishan Kumar Gorav
Krishan Kumar Gorav

Reputation: 57

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.

Upvotes: 1

Joshua G
Joshua G

Reputation: 2136

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.

Upvotes: 0

Related Questions