ContextSessionSecurityToken jest zastępowany, gdy drugi użytkownik loguje się w

Question

Mam problem występujący w pojedynczym środowisku produkcyjnym, które jest bardzo drapiące.

Masz dwóch użytkowników, A i B. Użytkownik A loguje się, wszystko działa poprawnie. Użytkownik B loguje się, a po zalogowaniu użytkownika B użytkownik A ma teraz ten sam token bezpieczeństwa co użytkownik B.

Nasz system WIF jest dość standardowy, wprowadzamy pewne niestandardowe roszczenia do tokena, ale wszystko inne wygląda standardowo w miarę jak token jest tworzony i przechowywany (obsługiwany przez WIF).

czuję, że może być uruchomiony w jakimś dziwnym przypadku krawędzi z WIF, że nie jestem zaznajomiony z

Aktualizacja: Zarówno A i B mogą być na oddzielnych komputerach, lub oddzielnych przeglądarek na tej samej maszynie.

Gdzie mamy token gdy zainteresowanie usługą

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); 

jeśli dodam zalogowaniu tu widzę sessionToken.ClaimsPrincipal.Identity.Name różni się od nazwy to ma być w tym momencie.

Answer 1

Widziałem podobny problem. Postanowiliśmy zmienić zasób pieniężny w usługach IIS i kodzie. Spieniężenie powodowało, że bezpieczeństwo wydawało się być pomieszane, ale serwer przechowywał tylko ostatni wynik wygenerowanego html, dzięki czemu wyglądało na to, że użytkownik A był zalogowany, a nie użytkownik B. Mam nadzieję, że to pomoże.

Answer 2

Czy strona ufająca i serwer STS (WIF) są hostowane na tych samych usługach IIS przy użyciu tej samej puli aplikacji? Jeśli tak, spróbuj użyć innej puli aplikacji, ponieważ proces roboczy czasami używa do zepsucia rzeczy. Mam nadzieję, że to ci pomoże.

Answer 3

Pomoże Ci, jeśli zamieścisz dodatkowe informacje dotyczące zarówno ustawień konfiguracji internetowej, jak i konfiguracji usług IIS i wersji .NET Framework. Dla mnie brzmi to jak problem z pulą aplikacji, ale z bardzo ograniczoną znajomością twojego systemu. Jeśli tożsamość puli aplikacji jest niestandardowa, to oczywiście dostęp do tego samego użytkownika, chyba że ustawiono system lokalny lub personifikację. Jeśli to nie jest problem, sprawdź ustawienia autoryzacji i upewnij się, że anioniczny i podstawowy jest wyłączony lub cokolwiek może być wymagane przez aplikację.