ContextSessionSecurityToken перезаписывается, когда второй пользователь регистрируется в

У меня проблема, возникающая в одной производственной среде, которая сильно царапается.

У вас есть два пользователя, A и B. Пользователь A входит в систему, все работает нормально. Пользователь B входит в систему и после входа пользователя B пользователь A теперь имеет тот же маркер безопасности, что и пользователь B.

Наша настройка WIF довольно стандартная, мы добавляем некоторые пользовательские требования к токену, но все остальное выглядит стандартно, насколько маркер создается и хранится (обрабатывается WIF).

Почувствуйте, как я могу столкнуться с каким-то странным случаем с WIF, который я не знаком с

Обновление: оба A и B могут быть на отдельных машинах или отдельных браузерах на одном компьютере.

Где мы получаем токен при запросе службы

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

Если я добавлю здесь регистрацию, я вижу, что sessionToken.ClaimsPrincipal.Identity.Name отличается от имени, которое предполагается в данный момент.

Ответы

Ответ 1

Используется ли ваша полагающаяся сторона и сервер STS (WIF) на одном и том же IIS с использованием того же пула приложений? Если да, попробуйте использовать другой пул приложений, как иногда используется рабочий процесс, чтобы испортить вещи. Надеюсь, это поможет вам.

Ответ 2

Я видел подобную проблему. Мы решили, что это будет изменение наличных средств на IIS и в коде. Обналичка заставляла безопасность казаться запутанной, но сервер просто сохранял последний результат созданного html, делая его похожим на то, что пользователь A был зарегистрирован, а не пользователь B. Надеюсь, это поможет некоторым.

Ответ 3

Это поможет, если вы разместите дополнительную информацию о любых настройках веб-конфигурации, а также конфигурации IIS и версии .NET Framework. Для меня это звучит как проблема пула приложений, но это связано с крайне ограниченными знаниями вашей системы. Если идентификатор пула приложений является обычным, конечно, доступ к одному и тому же пользователю, если не установлена ​​локальная система или олицетворение. Если это не проблема, проверьте свои настройки авторизации и убедитесь, что анонимные и базовые отключены или что-то еще, что может потребоваться вашему приложению.