Замените FormsAuthentication на SessionAuthenticationModule (SAM), чтобы сделать удостоверение с поддержкой утверждений.

У меня есть существующее приложение MVC4 (.NET 4.5), использующее FormsAuthentication , на который я собираюсь перейти с помощью SessionAuthenticationModule чтобы я мог получить информацию о заявках как для простых дополнительных данных для идентификации, так и в качестве первого шага к конечному переходу на выполнение аутентификации через WIF (Windows Identity Foundation) с помощью STS (Security Token Service). ), как ADFS (службы федерации Active Directory), но все это позже.

Мой вопрос: что определяет тайм-аут, когда пользователь аутентифицируется с помощью SessionAuthenticationModule?

Я использовал эта страница, чтобы моя аутентификация работала, и, похоже, она работает нормально. В основном моя аутентификация выглядит так.

Фрагмент из моего метода входа в систему

var personId = securityService.AuthenticateUser(model.Login, model.Password);

if (!personId.IsEmpty())
{
    authenticationService.SignIn(personId, model.RememberMe);
    if (Url.IsLocalUrl(model.ReturnUrl))
        return Redirect(model.ReturnUrl);
    else
        return RedirectToAction("Index", "Home");
}

AuthenticationService.SignIn()

public void SignIn(Guid personId, bool createPersistentCookie)
{
    var login = securityService.GetLoginByPersonId(personId);
    if (String.IsNullOrEmpty(login.Name)) throw new ArgumentException("Value cannot be null or empty.", "userName");

    var claims = LoadClaimsForUser(login.Name);
    var identity = new ClaimsIdentity(claims, "Forms");
    var claimsPrincipal = new ClaimsPrincipal(identity);
    var token = new SessionSecurityToken(claimsPrincipal, ".CookieName", DateTime.UtcNow, DateTime.UtcNow.AddMinutes(30)) { IsPersistent = createPersistentCookie };
    var sam = FederatedAuthentication.SessionAuthenticationModule;
    sam.WriteSessionTokenToCookie(token);
}

AuthenticationService.LoadClaimsForUser()

private IEnumerable<Claim> LoadClaimsForUser(string userName)
{
    var person = securityService.GetPersonByLoginName(userName);
    if (person == null)
        return null;

    var claims = new List<Claim>();
    claims.Add(new Claim(ClaimTypes.NameIdentifier, person.PersonId.ToString()));
    claims.Add(new Claim(ClaimTypes.Name, userName));
    /* .... etc..... */
}

Но единственная проблема, с которой я столкнулся, заключается в том, что я хочу сохранить поведение скользящего истечения срока действия, чтобы пользователю не предлагалось повторно войти в систему по истечении срока его входа в систему, но при работе над этой проблемой я заметил, что не могу найти от того, что определяет, как долго они остаются в системе вообще. Я установил время ожидания сеанса. , время ожидания форм и validTo в конструкторе SessionSecurityToken на 1 минуту, но даже по истечении этого времени я Я все еще могу получить доступ к сайту. Файл cookie появляется в браузере с датой истечения срока действия «Сеанс», и я не уверен, почему, но даже если файл cookie действителен для сеанса, токен, личность или что-то еще, что вы хотите назвать, истекает через 1 минуту и заставить пользователя снова войти в систему?


person Nick Albrecht    schedule 14.05.2013    source источник


Ответы (1)


Однажды у меня были похожие проблемы, вот мой вопрос, содержащий мой подход к аннулированию файлов cookie по истечении срока действия токена.

Как правильно установить время ожидания при объединении с ADFS 2.0

Добавление немного другой логики дает вам скользящий срок действия

http://brockallen.com/2013/02/17/sliding-sessions-in-wif-with-the-session-authentication-module-sam-and-thinktecture-identitymodel/

web.config — настройка MaxClockSkew

<system.identityModel>
  <identityConfiguration>
    <securityTokenHandlers>
      <securityTokenHandlerConfiguration maximumClockSkew="0">
        </securityTokenHandlerConfiguration>
    </securityTokenHandlers>
  </identityConfiguration>
</system.identityModel>
person Wiktor Zychla    schedule 14.05.2013
comment
На самом деле это очень близко к тому, что я в конечном итоге сделал для скользящего истечения срока действия, но я закомментировал все это, когда заметил, что не имеет значения, обновил ли я токен сеанса, который изначально не соблюдался. И вы правы, я МОГУ вручную истечь срок действия токена, но это действительно заставляет меня задаться вопросом, какой смысл использовать validFrom и validTo в токене, если они не соблюдаются, и что заставляет запрашивать мои учетные данные снова через некоторое время, если это не тайм-ауты, которые я установил? - person Nick Albrecht; 15.05.2013
comment
Не могли бы вы попробовать установить время экспирации на 5 минут или больше и повторить тест? Wif имеет перекос часов 5 минут, и, если я правильно помню, автоматическое истечение срока действия работает правильно, если токен действителен не менее 5 минут. - person Wiktor Zychla; 15.05.2013
comment
Да, это сработало. Как только я установил максимальное отклонение часов на 0, оно заработало именно так, как я ожидал. Добавил путь к вашему ответу. Большое спасибо! В распределенной среде перекос часов, вероятно, полезен, но в моем случае все это находится в одной системе, поэтому мне это не нужно. - person Nick Albrecht; 15.05.2013