Время жизни сессии

После прохождения процедуры аутентификации пользователя с использованием интерактивных сценариев (в браузере) между пользователем и сервером устанавливается сессия, в рамках которой все последующие запросы на аутентификацию выполняются прозрачно и не требуют действий пользователя.

По умолчанию сессия существует до закрытия браузера или явного выполнения операции выхода из Веб-интерфейса Пользователя или веб-интерфейса интегрируемой системы.

Чтобы более точно контролировать время жизни сессии, необходимо использовать специальные параметры в командлете Set-IdsAccountPolicy.

Set-IdsAccountPolicy -SessionCookieExpireSeconds 480 -SessionCookieSlidingExpiration $true

где

  • SessionCookieExpireSeconds задает время жизни сессии в секундах, после истечения которого потребуется повторная аутентификация пользователя. Значение 0 включает режим по умолчанию (сессия не заканчивается до явного выхода или закрытия браузера).
  • SessionCookieSlidingExpiration включает или отключает режим "скользящей" сессии, если пользователь проявлял активность в интервале [SessionCookieExpireSeconds/2,SessionCookieExpireSeconds], то время жизни продлевается еще на SessionCookieExpireSeconds секунд.

Следующие действия принудительно разрывают сессию на всех устройствах пользователя:

  • изменение пароля пользователя,
  • блокировка пользователя,
  • изменение политики подтверждения,
  • изменение политики доступа.

Сессии в веб-приложениях, использующих протокол OAuth 2.0

Информационные системы, использующие для контроля доступа к ресурсам протокол OAuth 2.0 (в т.ч. OpenID Connect 1.0), могут контролировать время жизни сессии с помощью маркеров обновления (refresh tokens).

Во время работы пользователя возникают две независимые сессии:

1. Между браузером пользователя и Центром Идентификации (ЦИ).

2. Между браузером пользователя и OAuth-клиентом (информационной системой).

Сессия между браузером и ЦИ

Сессия основана на cookies, устанавливаемых после успешной аутентификации пользователя, время жизни данных cookies, а следовательно, и всей сессии регулируется параметром SessionCookieExpireSeconds, задающим время жизни cookies в секундах. Если параметр равен 0, то создаются cookies, живущие до закрытия браузера. Дополнительно можно использовать параметр SessionCookieSlidingExpiration, управляющий созданием т.н. скользящей сессии: если очередное обращение к ЦИ происходит во второй половине интервала SessionCookieExpireSeconds, то ЦИ выпустит новые сессионные cookies, продлевая тем самым срок действия сессии.

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

Возможность запомнить пароль регулируется настройкой DisableKmsi (Disable Keep Me Signed In) командлета Set-IdsAccountPolicy, если она выставлена в $true, то чекбокс "Запомнить пароль" не отображается.

Возможность запомнить факт прохождения вторичной аутентификации для входа на этом устройстве регулируется настройкой DisableKdsi (Disable Keep Device Signed In) командлета Set-IdsAccountPolicy, если она выставлена в $true, то чекбокс "Запомнить на этом устройстве" не отображается.

Примечание

Сохранение факта прохождения вторичной аутентификации распространяется только на операцию подтверждения входа пользователя, на подтверждение любых других операций (подпись, расшифрование и т.д.) сохранение не распространяется.

Удаление запомненных данных происходит при выполнении протокола закрытия сессии (см. OpenID Connect RP-Initiated Logout 1.0, Веб-интерфейс реализует данный протокол).

Пример

Set-IdsAccountPolicy -SessionCookieExpireSeconds 60 -SessionCookieSlidingExpiration $true

В данном примере устанавливается значение 60 секунд в качестве времени жизни cookies и включается режим скользящей сессии.

Сессия между браузером и OAuth-клиентом

После успешной аутентификации пользователя ЦИ создает сессионные cookies и выпускает маркер доступа (access token). При соответствующих настройках ЦИ также создаст маркер обновления, который можно использовать для гибкой настройки сессий в OAuth-клиенте.

Маркеры доступа используются для контроля доступа к защищаемым ресурсам (Сервис Подписи, Сервис Управления Пользователями ЦИ, Сервис Обработки Документов, Сервис Аудита). Срок действия маркера доступа, задаваемый командой Set-IdsClient -AccessTokenLifetime, рекомендуется делать минимально необходимым для корректной работы (по умолчанию 300 секунд), так как у пользователя нет возможности отозвать его. Необходимо учитывать, что требовать от пользователя каждый раз проходить очередную аутентификацию после истечения срока действия маркера доступа приводит к плохому пользовательскому опыту (даже в том случае, если между ЦИ и пользователем установлена сессия на основе сессионных cookies) и создает нежелательную нагрузку на сам ЦИ. Чтобы OAuth-клиент мог получать новые маркеры доступа, не прибегая к повторной отправке пользователя за авторизацией, используются маркеры обновления.

Срок действия маркера обновления, задаваемый командой Set-IdsClient через параметр -RefreshTokenLifetime, может быть значительно больше срока действия маркера доступа, так как пользователь и Оператор через API могут отозвать выпущенные маркеры обновления, тем самым прервав сессию с OAuth-клиентом. Пока действует маркер обновления, OAuth-клиент не перенаправляет пользователя за повторной авторизацией, а использует специальный сценарий Refresh Token Flow для получения нового маркера доступа без взаимодействия с пользователем, таким образом сессия между OAuth-клиентом и пользователем основана на маркере обновления, а ее срок жизни регулируется параметром RefreshTokenLifetime.

После истечения маркера обновления пользователь будет перенаправлен в ЦИ за повторной авторизацией, если к этому моменту у него уже нет действующей сессии с ЦИ, то будет запрошена аутентификация (при этом следует учитывать наличие долговременных cookies и запомненного устройства).

Расширенные настройки: скользящая сессия

Часто одного абсолютного времени сессии (после истечения которого у пользователя всегда запрашивается повторная авторизация в ЦИ) бывает недостаточно, иногда требуется организовать более гибкий подход на основе скользящих сессий. В случае использования скользящих сессий выбиирается интервал времени, называемый периодом неактивности. Если в течение периода неактивности пользователь не выполнял никаких действий, то сессия разрывается.

Для организации скользящих сессий на основе маркеров обновления используется параметр RefreshTokenExpirationType, если в качестве значения данного параметра задано Sliding, то для вычисления срока действия маркера обновления вместо значения параметра RefreshTokenLifetime начинает использоваться значение другого параметра: RefreshTokenSlidingLifetimeSeconds. Если очередной запрос на получение маркера доступа поступает во второй половине интервала RefreshTokenSlidingLifetimeSeconds, то ЦИ продлевает срок действия маркера обновления еще на RefreshTokenSlidingLifetimeSeconds секунд, при этом суммарное время жизни маркера обновления не может превышать RefreshTokenLifetime (подробно поведение описано в соответствующем разделе).

Примечание

После истечения срока действия маркера обновления получить новый маркер доступа можно только запросив повторную авторизацию. Для этого браузер пользователя перенаправляют в ЦИ, если при этом между ЦИ и пользователем есть активная сессия, то авторизация будет выполнена прозрачно (без аутентификации). Например, если значение параметра SessionCookieExpireSeconds равно 0, и пользователь работает с ЦИ и OAuth-клиентом в одном и том же браузере, то авторизация всегда будет проходить прозрачно для пользователя, более того, это может создать и негативный пользовательский опыт (мелькание страницы в браузере при переходе в ЦИ и обратно, появление ни к чему не приводящих сообщений об истечении сессии в OAuth-клиенте), поэтому при необходимости реализации сессий в OAuth-клиенте требуется устанавливать значения SessionCookieExpireSeconds отличными от 0.

Существует два типа маркеров обновления: одноразовый и переиспользуемый. Одноразовый маркер можно использовать для получения нового маркера доступа только один раз, после чего он становится недействительным, а ЦИ в ответе с маркером доступа возвращает новый маркер обновления. Переиспользуемый маркер обновления, напротив, можно многократно использовать, пока срок его действия не истечет.

Переиспользуемые маркеры обновления удобно применять, когда OAuth-клиент является веб-приложением, в котором отсутствует единое серверное хранилище состояния сессии (такое как, например, база данных). В этом случае состояние сессии, как правило, сохраняется на стороне браузера (в cookies, в SessionStore и т.п.), такой способ хранения не подразумевает частого обновления состояния, в свзяи с чем хранить там одноразовые маркеры обновления и заменять их после очередного использования на новые оказывается очень неудобным. Для таких сценариев хорошо подходят переиспользуемые маркеры обновления: такой маркер достаточно один раз сохранить на стороне клиента в браузере при старте приложения (например, в cookies) и затем использовать в течение всего времени жизни сессии.

Настройка механизма скользящей сессии

Веб-интерфейс является OAuth-клиентом, в котором можно реализовать механизм скользящей сессии. Для этого требуется:

1. Выставить абсолютное время жизни маркера обновления (-RefreshTokenLifetime): через это время пользователя перенаправят в ЦИ для прохождения повторной авторизации (например, можно выставить это значение в продолжительность рабочего дня).

2. Выставить тип истечения маркера обновления (-RefreshTokenExpirationType) в Sliding, данная настройка включит режим скользящих сессий.

3. Выставить скользящее время жизни маркера обновления (-RefreshTokenSlidingLifetimeSeconds): это время определяет период неактивности пользователя, если в течение этого времени в ЦИ не поступали запросы на использование маркера обновления, то сессия будет разорвана и пользователю потребуется заново пройти процедуру авторизации.

4. Выставить тип использования маркера обновления (-RefreshTokenUsage) в значение ReUse. Это позволит избежать изменения значения маркера обновления и упростит его хранение на стороне Веб-интерфейса.

Пример

Исходные данные:

  • Время неактивности: 900 с.
  • Максимальное время сессии: 3600 с (1 час).
  • Время жизни маркера доступа: 300 с.

В примере в качестве значения ClientId для Веб-интерфейса используется cryptopro.frontend.Frontend.

Время неактивности является ключевым параметром, влияющим на значения настроек OAuth-клиента, зарегистрированного в ЦИ. Для задания времени неактивности в 900 секунд и максимального времени сессии в 3600 секунд требуется выполнить следующие команды.

Set-IdsAccountPolicy -SessionCookieExpireSeconds 900 -SessionCookieSlidingExpiration $true

Set-IdsClient -ClientId cryptopro.frontend.Frontend -RefreshTokenLifetime 3600 -RefreshTokenExpirationType Sliding -RefreshTokenSlidingLifetimeSeconds 900 -RefreshTokenUsage ReUse

где

  • RefreshTokenLifetime - абсолютное время жизни маркера обновления.
  • RefreshTokenExpirationType - тип истечения маркера доступа, Sliding - скользящее истечение, Absolute - абсолютное.
  • RefreshTokenSlidingLifetimeSeconds - скользящее время жизни маркера обновления, задает максимальный период неактивности в секундах.
  • RefreshTokenUsage - тип использование маркера обновления, ReUse - переиспользуемый, OneTime - одноразовый.

В случае с Веб-интерфейсом параметр SessionCookieExpireSeconds необходимо настроить так, чтобы при истечении периода неактивности (т.е. скользящего времени действия маркера доступа), когда пользователь будет отправлен в ЦИ для повторной авторизации, сессионные cookies были истекшими, иначе процедура авторизации будет выполнена прозрачно, без аутентификации.

За 15 секунд до истечения срока действия маркера доступа Веб-интерфейс может отобразить сообщение о скором истечении сессии, если пользователь нажмет кнопку Продлить, то он будет отправлен в ЦИ за повторной авторизацией, при этом, если период SessionCookieExpireSeconds еще не прошел, авторизация будет выполнена прозрачно.

Максимальное время жизни маркера обновления отвечает за максимальную продолжительность сессии пользователя (максимальное время жизни равно RefreshTokenLifetime + AccessTokenLifetime, это время соответствует ситуации, когда последний маркер доступа был получен на исходе максимального времени жизни маркера обновления).

Время жизни маркера доступа в примере (300 секунд) является значением по умолчанию при установке нового экземпляра. Так как при истечении жизни маркера доступа Веб-интерфейс начнет процедуру его обновления, отправляя в ЦИ соответствующий запрос, то время жизни маркера доступа определяет, как часто Веб-интерфейс будет обращаться к ЦИ. Значение по умолчанию подходит для большинства разворачиваний и требует изменения только в исключительных и обоснованных ситуациях (например, такой ситуацией может быть использование в качестве периода неактивности интервала меньшего или сравнимого с временем жизни маркера доступа).